[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: Paul Smith
Subject: Re: Some serious issues with the new -O option
Date: Wed, 01 May 2013 16:27:58 -0400

On Wed, 2013-05-01 at 22:08 +0300, Eli Zaretskii wrote:
> Yes.  But I thought the change was about -Otarget, not -Ojob.  Stefano
> was complaining about a plain -O, so -Ojob is not what was his
> problem.

Yes, it is about -Otarget.  As I said, I added -Ojob output "just for
completeness".  The important distinctions (for this thread) are between
-Otarget and -Omake.  If you see the behavior I describe for those two
flags then things are working as expected.

If you still see choppiness in the output with -Otarget and you see the
behavior I describe, I'd be interested to know more about the targets
you're building.  I'd also be interested to know if using -Otarget vs.
-Ojob makes any difference in the choppiness.

If your recipe normally runs for 5 seconds (say) and it continually
generates output during that time, then yes, certainly the -O feature
will result in choppiness because instead of a sequence of continuous
output over 5 seconds you get 5 seconds of silence, followed by all the
output.  That is the nature of the beast... if this bothers you (more
than having interleaved parallel output) best to not use -O.

I suggest that for MOST makefile targets, this is not the normal
behavior.  Most makefile targets (building a .o for example) are built
relatively quickly and, more importantly, they don't expect to see much
output except on failure.

I would also point out that the more output your targets generate the
more likely you are to get output corruption when running with high -j,
and the more you'd be likely to benefit from -O.

> That is completely unexpected for me: I thought that -Otarget meant
> that all the output from making a target, e.g. rec1, will be output as
> a single unit.  If that's not the intent, then why is it called
> "target"?

That IS the intent.

However, in the presence of makefile recursion this model fails.
Consider if you have a makefile, like every single automake makefile for
example!, where the "top-level" target is nothing more than a recursive
invocation of a sub-make with some extra arguments, and the sub-make
actually does all the work:

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

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.

I think this makes the output sync feature much less useful: it's only
appropriate for building in the background where no one looks at the
output until it's done.  If you want that behavior, though, that's
exactly what the -Omake option selects so it's available.

For -Otarget we introduce an exception to deal with this problem: if we
detect we're about to invoke a recursive make, we do NOT redirect the
output to the temp file.  We let each target of that make print its
output immediately.  This way you don't have to wait for an entire
recursive make to finish before you see any of its output.

> Why is it important to make that exception?  And shouldn't we have an
> option _not_ to make such an exception, but without -Omake,
> i.e. without waiting for the whole session to end?  Whenever any
> top-level recipe finishes, it is flushed to the screen as a single
> unit.  Does this make sense?

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.

If we can improve on this I'm very interested to hear the details.

reply via email to

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