[Top][All Lists]

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

Re: Some serious issues with the new -O option

From: Eli Zaretskii
Subject: Re: Some serious issues with the new -O option
Date: Thu, 02 May 2013 20:24:39 +0300

> From: Paul Smith <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Thu, 02 May 2013 08:21:23 -0400
> > > Now, if you do nothing special for recursive make, you'll get no output
> > > from the entire build until it is completely done, because all the
> > > output from the recursive make command is going to the temporary file
> > > for that target, then it all gets dumped at the same time.
> > 
> > Not every Makefile looks like that on its top level.  I agree that we
> > should cater to the above, but perhaps we could do that without
> > "punishing" the other use cases.  For example, perhaps we should have
> > a -Osub-make option that will _not_ activate sync-output on the top
> > level, only in the sub-make's.  This should produce the desired
> > results, I think.
> Can you clarify what the "desired results" are?  I seem to have lost the
> thread.  What is the behavior you see now that you are trying to avoid
> (or you don't see that you're trying to achieve)?

The "desired results" in my original use case are that the output of
remaking each target is shown as one chunk in the order in which it is
expected, i.e. from the first command to the last.  "Remaking a
target", a.k.a. "recipe" in this context are all the commands that
rebuild a single target.  E.g., in this snippet:

foo: bar
     $(MAKE) -C foo something-else

all the 4 commands and whatever they emit should be output in one go,
and in the order they are in the Makefile.

The "desired results" in the example you showed, i.e.

>    all: config.h
>            $(MAKE) $(AM_MAKEFLAGS) all-recursive

are that -O is in effect only for the sub-make which runs

> Capture of the sub-make will mean that the entire output of that
> sub-make, and all of its recipes including ITS sub-sub-makes, will be
> sent to a temporary file and not displayed on the screen until the
> entire sub-make is completed.  In what situation would we want to choose
> this, regardless of level of sub-make?

Not "regardless of level", of course.  If there are many levels of
recursion, then doing that is not what most people will want.  But if
"make all-recursive" does not recurse anymore, then yes, what I
described will be good.

> In general I see no benefit in trying to special-case any particular
> level of make.  For some builds the top level does all the work.  For
> some the second level.  For some the third.  For many, different levels
> for different parts of the same build.

The user always knows what she is going to run, or at least ought to
know.  I think we already established that blindly appending -O to the
Make command might cause surprising and even disappointing or annoying
results, if one does it for a use case that does not play well with
this feature.  So some degree of adaptation between -O and its
sub-modes to the depth and "breadth" (in parallelism sense) of the
build is necessary anyway.

> > > I don't understand the change that you're suggesting.  That's exactly
> > > what -Omake does today: whenever any recipe finishes it is flushed to
> > > the screen as a single unit, and no special handling is given to
> > > recursive makes.
> > 
> > In my case, I see all the output at once.  Maybe I misunderstand what
> > -Omake is supposed to do, too.
> I think you and I said the same thing: the output from recursive makes
> is saved up and flushed all at once...?

No, that's not what I said.  I said whenever a _recipe_ finishes, not
whenever the entire Make run finishes.

reply via email to

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