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 <h...@highlandsun.com> wrote: > Chiheng Xu wrote: >> >> On Fri, Jul 30, 2010 at 6:01 PM, Howard Chu<h...@highlandsun.com> wrote: >>> >>> Chiheng Xu wrote: >>>> >>>> On Fri, Jul 30, 2010 at 5:35 PM, Eli Zaretskii<e...@gnu.org> 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 > Bug-make@gnu.org > 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/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make