On Fri, 2013-05-03 at 16:16 +0300, Eli Zaretskii wrote: > > From: Paul Smith <psm...@gnu.org> > > Date: Fri, 03 May 2013 08:57:57 -0400 > > Cc: bug-make@gnu.org > > > > I think having this facility built into make is a win, especially as > > parallel builds become predominant. I would be even more happy about it > > if we can get it to the point where it can be enabled by default, and > > users don't even have to worry about it. > > I think enabling it by default will be a no-brainer if/when we come up > with a way to get it to produce the same output as without -j. IOW, > run a parallel build, but output its results as if it were a > non-parallel build.
If you mean literally exactly the same as a non-parallel build, that is enormously difficult. Doing that would require that instead of dumping output in the order that jobs finish, make would have to remember the order in which they were started and dump the output in that order. This ordering would have to be maintained across recursive make invocations. This also means that either we have to divorce the handling of the temporary files from the job (so we can maintain these temporary files after the job completes, until we have permission to dump them), or else we will lose parallel capability as jobs finish, but new ones can't be started until the old ones can dump their output. I'm not going to commit to implementing that before enabling some kind of sync output by default (actually I don't think it's solveable at all). And I don't see any justification for making such a requirement, since parallel builds today don't make that requirement. My position is if we can get output sync to a level where it is no worse than today's parallel build behavior (excepting the issue of output to a TTY vs. file which can never be resolved), we should enable it by default. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make