Re: Another issue with -O?

[Paul Smith]

On Sat, 2013-05-04 at 09:57 +0300, Eli Zaretskii wrote:
> > From: Paul Smith <address@hidden>
> > Cc: address@hidden, address@hidden
> > Date: Fri, 03 May 2013 16:51:47 -0400
> > 
> > > I think enabling [-O] 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.
> 
> Yes, literally, but with one exception: the order of producing on the
> screen output from targets that are remade in parallel (i.e. are
> independent of each other), and are on the same level of recursion,
> does not have to be preserved.

Well that's not "literally exactly the same" then :-).

But I won't agree to the caveats here, in particular the phrase "on the
same level of recursion".  Today with parallel builds and recursion, we
don't guarantee anything about the order of execution between different
sub-makes and as I mentioned, I see no justification for adding that new
requirement to synchronized output.

> Example:
> 
> all: a b
> a: xa
>       @echo $@
> xa xb xc:
>       @echo $@
> b: xb xc xd
>       @echo $@
> xd:
>       $(MAKE) foo
>       @echo $@

> By contrast, I _would_ mind to see this, for example:
> 
>   xa
>   xb
>   a
>   xc
>   xd
>   $(MAKE)
>   b

I agree that is less than ideal and is one of the two issues I mention
below.  This will be fixed.  However, you may see this:

  xa
  xb
  a
  $(MAKE) foo
  xc
  xd
  b

There's nothing that can be done about that (and that's true of today's
parallel build as well).

> > My position is if we can get output sync to a level where it is no worse
> > than today's parallel build behavior
> 
> If we want it to be "no worse", then why do we need it at all, let
> alone have it turned on by default?  I thought -O should actually
> improve something, so "no worse" is too weak to describe that, IMO.

Obviously we gain synchronized output.  I mean, "no worse" in terms of
other behavior.

> And what are our criteria for deciding whether it's no worse?  The
> current default behavior might be confusing and hard to interpret in
> some cases, but at least it's familiar.  -O changes that to a
> different behavior which is confusing (at least to me) in different
> situations, and is unfamiliar.

I believe we can get to the point where anyone who can read and
understand parallel output can even more easily read and understand the
output from -O.  Conceptually all we're doing is ensuring the output
comes out at the same time, uninterrupted, instead of interleaved.  It
should not be hard to understand that.

There are two known issues right now that are causing confusing output.
Hopefully once I fix those the output will make more sense than normal
parallel output.