From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-05-19 15:21:26
Dirk Griffioen wrote:
>>> Very weird. Yes, the key change would be the buffering of action
>>> output. No idea how it could conflict with things like IncrediBuild
>>> and Python though. Since in the end it does a regular fwrite back to
>> Well, I can't wait to finally see a reproducible test case... I've
>> gone thorough that code and also do not see how it could interfere
>> with external output processing... it just delays it for a while...
> Yes, but what if 2 different 'entities' try to write to stdout?
> All output is delayed yes? And all is written at once?
The subtasks bjam runs are captured through pipes into internal buffers.
When they complete the bjam main process replays the output to stdout.
This means that since only one process is doing the output, it is *all*
> The case I have is
> - a .bat file echoing status
> - iconv converting sqlscripts/data to utf8 *via* stdout (by redirection)
> The status echo's from the .bat file end up in the converted sql file -
> it's all written at once see
> And now my sql file is invalid, breaking the create database, breaking
> the regression, breaking the build ...
> Or am I missing something here?
Only thing I can think of is if the shell is making some assumptions as
to how it's own output is being processed. But that would fall under the
category of a Windows bug.
> Could the dealy write be optional? (Just a thought)
It's been suggested... But it's just not possible.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk