Re: [RFC]serialize the output of parallel make?

[Tim Murphy]

Hi,

One of the major problems with log output that is interleaved is that
you cannot tell what went wrong in your build because errors become
disassociated with the recipe that they belong to.

Some compilers etc get away with this because there is enough
information in a single line of error output to tell you everything
you need to know: e.g. error: fred.cpp: syntax error on line 345

It becomes worse for any situation that is a little more complicated,
e.g. where there is a string of commands in a recipe or when you are
using tools whose output does not have all the context.

e.g.
gcc -o fred fred.cpp
perl makedef.pl -i something.def
perl prepdef.pl  -i otherthing.def
error: fred.cpp: syntax error on line 345
ERROR: File not Found


Which file was missing?  If you can't change the tool to print every
detail then what do you do?


Regards,

Tim

On 30 July 2010 11:16, Howard Chu <address@hidden> wrote:
> Chiheng Xu wrote:
>>
>> On Fri, Jul 30, 2010 at 6:01 PM, Howard Chu<address@hidden>  wrote:
>>>
>>> Chiheng Xu wrote:
>>>>
>>>> On Fri, Jul 30, 2010 at 5:35 PM, Eli Zaretskii<address@hidden>    wrote:
>>>>>
>>>>> I asked for an example.  Could you please show a "messy" output and
>>>>> the output you'd like to have after "serialization"?
>>>>>
>>>>> TIA
>>>>>
>>>>
>>>> serially make : execute  A, B, C programs, they print:
>>>>
>>>> A:  Hello, I'm A, I am from Earth.
>>>> B:  The moon is my home.
>>>> C:  Welcome to Mars, It's an amazing planet.
>>>>
>>>> parallely make : the output of A, B, C programs interleave :
>>>>
>>>> C:  Welcome to
>>>> B:  The moon is my
>>>> A:  Hello, I'm A, I am from Earth.home.Mars, It's an amazing planet.
>>>
>>> This seems like quite an extreme example. stdout is line buffered by
>>> default, so individual lines would get written atomically unless the
>>> programs you're running are doing weird things with their output. In the
>>> common case interleaving like this doesn't happen within lines, it only
>>> happens between lines of multi-line output. stderr may skew things since
>>> it's usually nonbuffered, but again, that's not the common case.
>>>
>>
>> I use "make -j 4" to build and test gcc, the situation above is very
>> common.
>
> Then it means you're getting a lot of diagnostics written to stderr, and you
> should probably look into why you're getting so many. I routinely do large
> builds with "make -j24" on a 16 core server and the output doesn't have
> problems like that. If you're getting lots of diagnostics while building
> gcc, then you're probably going to wind up with a broken compiler when it's
> done.
>
> Garbage-in-garbage-out. Prettying up the make output isn't going to solve
> that.
> --
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/
>
> _______________________________________________
> Bug-make mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-make
>



-- 
You could help some brave and decent people to have access to
uncensored news by making a donation at:

http://www.thezimbabwean.co.uk/