Let me add my voice as a user. If you are one of the lucky people whose builds consist mostly of 1 line of output per rule then you will rarely have any trouble in a good build but try interpreting error messages from compiler/tool X when they're 10 lines from the file that they refer to and don't include the filename in the error message. Try working it out when it's not your code that's being built.
This suggests an optimisation where you buffer 5 lines in memory and open a file if there's more but I wouldn't be surprised if the gain is quite small as I suspect that the average build step does so much IO as to make a buffered temp file for the output seem a relatively tiny overhead. I have certainly spent a lot of time wondering why xyz.cpp doesn't have a line 370. I faced this 5 years ago and we had to come up with our own solution rather than wait to convince GNU mission control that we had a problem - which was the only choice given the great difficulty at that job of trying to get permission to make open source contributions. It has already been a very long time coming. You've got it now, thank goodness, in whatever shape or form. Please turn it on. As for reasons: a) I would be surprised if there weren't other changes in the next release that give some people pause for thought before upgrading - why worry about 1 more? e.g. globbing differences between various recent releases caused more pain to me than this is likely to. b) Demand is usually only going to come from the few anyhow. I think this is one of those features that few people will know to turn on but many will benefit anyhow. The reason is that you will start to be able to write generic make output analysis tools. I don't know if you guys have seen Electric Insight, for example. I don't intend this as a plug but I can't help it - it's just the only non-inhouse example that I can think of but I have seen a number of others at various companies. This is a trivial example where you can see that parsing is taking most of the time in this parallel build: https://docs.google.com/file/d/0BwJNUxZZ7qItQlRrUjBmM0tTTDg/edit?usp=sharing It lets you see the state of your parallel build - gives you an intuitive idea of where the time is going and what the errors are and so on. You can't implement tools like this across a general a lot of builds unless they have contiguous recipe output and the surest way to get that is for it to be on by default. You also need recipe separators and timing data but I think you'll realise that eventually now that this step is taken. c) Lets benchmark it on something like an android build and you can make a decision after that? Heck, lets try it with various things and be happy it works. Regards, Tim On 29 April 2013 03:53, Eli Zaretskii <e...@gnu.org> wrote: > > From: Paul Smith <psm...@gnu.org> > > Cc: bug-make@gnu.org > > Date: Sun, 28 Apr 2013 22:03:39 -0400 > > > > Now that we seem to have a workable solution for output synchronization > > for both POSIX and Windows systems, I wonder if we shouldn't consider > > enabling it as the default mode when parallel builds are running. > > I don't think we should do this unless users demand it, which means we > should wait for the next release and some time beyond before making > the decision. > > FWIW, I'm running 8-way parallel Make jobs for many months now, and > never had any trouble interpreting their output, neither when they > succeed, nor when they don't. > > The synchronized output operation annoys me slightly in that there are > distinct time intervals when Make says nothing at all, and then the > output appears in large chunks that get dumped en-masse to the > screen. IOW, the user experience is different and takes time to get > used to. > > _______________________________________________ > Bug-make mailing list > Bug-make@gnu.org > https://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/friends/
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
