On Saturday, July 28, 2012, Evan Martin <
mar...@danga.com> wrote:
> I wonder, can we do this automatically? Whenever we're running a
> single command, we know that all the rest of the build is blocked on
> that command completing. We won't start up another command in
> parallel until that command completes, so it's safe to print its
> output while it runs.
A friend of mine suggested roughly the safe. I have to confess that it is simpler. However, I know how to test if there is one task in the plan, but I don't know how to test if a task is a connection point between two sub-graph in the graph. Maybe, just the first test would be enough.
Did not about this one.
PS: Sorry for the poor English of my previous post.
>
> On Sat, Jul 28, 2012 at 6:44 AM, Nicolas Desprès
> <
nicolas...@gmail.com> wrote:
>> Hi,
>>
>> Although, Ninja's short output status is fine 99% of the time, it is not
>> always the case. For long lasting commands generating a long output like
>> configuration stage, documentation generation, test executions, etc...
>>
>> I tried to address this issue in this pull-request:
>>
https://github.com/martine/ninja/pull/382. Specially the case of the
>> configuration stage. It introduces a new rule attribute. This attribute is
>> just a hint for flushing the output. If the command is run in parallel of
>> other jobs, no flush happens. Actually, this most of the time the case. You
>> can also use a variable to flush on a per build basis. I needed this
>> behavior for the CMake generator (the CUSTOM_COMMAND rule is used in many
>> different context some requiring to flush and some not) but I finally did
>> not use it since it would have been too intrusive in the CMake code. I have
>> rather added a -F flag. It is way easier to implement, use and it does the
>> job for documentation generation, test executions, etc...
>>
>> Comments?
>>
>> Cheers,
>> Nico
>>
>