bug-make
[Top][All Lists]
Advanced

[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 14:41:25 -0400

On Wed, 2013-05-01 at 18:26 +0300, Eli Zaretskii wrote:
> You forgot to make the same change in the WINDOWS32 branch.  I did
> that in commit a87ff20.

Sorry, I missed that.

> > This should be fixed now.  Those who use recursive makefiles and were
> > seeing annoying delays in output with -O, please try again with the
> > latest commit and see if it works any better for you now.
> 
> Unfortunately, the delays are still here.

Very odd.  This is the test program I used; can you verify:

  recurse: ; $(MAKE) -f $(firstword $(MAKEFILE_LIST)) all
  all: 2 4 6
  .RECIPEPREFIX := |
  2 4 6 :
  |@ echo start $@
  |@ sleep $@
  |@ echo end $@

Now running:

  $ make -Omake --no-print-directory -j -f ...

should wait for 6 seconds, then print everything at the end.  Running
this on the other hand:

  $ make -O --no-print-directory -j -f ...

should show "start 2"/"end 2" after 2 seconds, "start 4"/"end 4" after 2
more seconds (4 total), etc.

And, just for completeness, running this:

  $ make -Ojob --no-print-directory -j -f ...

should show all the "start 2", "start 4", "start 6" right away (possibly
out of order), then after 2 seconds "end 2", then 2 seconds later "end
4", etc.

Is that what you see?  If so then the feature is working as expected.
I'd be interested to know more details of the makefiles where you're
still seeing stuttering behavior.  Are the targets in this environment
printing a lot of output per recipe?

> Moreover, it looks like
> this change introduced some kind of regression.  With the following
> Makefile:

I don't think this is a regression.  It's unfortunate but I don't see
any alternative.

BTW, you might find it simpler to use --no-print-directory as above to
get rid of the enter/leave stuff until I work out how to do it better.

> Notice in particular how start rec1..stop rec1 occludes its
> sub-targets, and the same for rec2.

"Occludes"?  I don't sense anything occluded here.  Maybe a terminology
error... did you mean something like "brackets"?

Yes, that's the behavior we'd expect to see if make was not treating the
sub-make properly: it saves up the sub-make output and prints it once
the sub-make is completed.  The goal of this fix is to change that...

> After the change I see this:

>   gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-05-01'
>   gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-05-01'
>   start rec1
>   stop rec1
>   start rec2
>   stop rec2
> 
> And now rec1 and rec2 are announced only at the end.

This isn't a bug, this is expected behavior.  It's slightly unfortunate,
I agree.  Consider your rule:

> rec1 rec2:
>         @echo start $@
>         $(MAKE) -f mkfsync simple
>         @echo stop $@

Here we have a 3-line recipe: the first and third are not considered by
make to be recursive, while the second one is (due to the presence of
$(MAKE))

When we run with -O (-Otarget), make will save up the output from the
entire recipe and print it at the end, EXCEPT that output from a
recursive line is not saved: that's the entire point of this feature, to
allow sub-makes to show their output as they go.

So, the results of lines one and three (the echo's) are saved until the
"rec1" target is completely built, and printed at the end, while the
results of the make invocation in between are not saved, which is just
what you see.

If you want different behavior you can change your rule to use "+" on
the two echo lines, so that they're also considered recursive and not
saved up.  Now this recipe is basically run in -Ojob mode, BTW.  "+" has
other side-effects though (running even in -n mode) which might be
unpleasant.

The only alternative to this would be for make to try to figure out if
ANY of the lines in the recipe will be recursive, and if so treat ALL
the lines as if -Ojob was enabled (show output as soon as the line is
complete), while not treating them as recursive.  However since today we
don't parse lines completely until we're about to execute them, this
would be a not-insignificant change I think.




reply via email to

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