bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another issue with -O?


From: Paul Smith
Subject: Re: Another issue with -O?
Date: Fri, 03 May 2013 16:51:47 -0400

On Fri, 2013-05-03 at 16:16 +0300, Eli Zaretskii wrote:
> > From: Paul Smith <address@hidden>
> > Date: Fri, 03 May 2013 08:57:57 -0400
> > Cc: address@hidden
> > 
> > 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]