[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: |
Wed, 01 May 2013 22:08:53 +0300 |
> From: Paul Smith <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Wed, 01 May 2013 14:41:25 -0400
>
> > 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?
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.
> I don't think this is a regression. It's unfortunate but I don't see
> any alternative.
Too bad.
> > 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.
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"?
- Re: Some serious issues with the new -O option, Paul Smith, 2013/05/01
- Re: Some serious issues with the new -O option, Stefano Lattarini, 2013/05/01
- Re: Some serious issues with the new -O option, Eli Zaretskii, 2013/05/01
- Re: Some serious issues with the new -O option, Stefano Lattarini, 2013/05/01
- Re: Some serious issues with the new -O option, Paul Smith, 2013/05/01
- Re: Some serious issues with the new -O option,
Eli Zaretskii <=
- Re: Some serious issues with the new -O option, Paul Smith, 2013/05/01
- Re: Some serious issues with the new -O option, Eli Zaretskii, 2013/05/01
- Re: Some serious issues with the new -O option, Tim Murphy, 2013/05/02
- Re: Some serious issues with the new -O option, Paul Smith, 2013/05/02
- Re: Some serious issues with the new -O option, Eli Zaretskii, 2013/05/02
- Re: Some serious issues with the new -O option, Paul Smith, 2013/05/02
- Re: Some serious issues with the new -O option, Eli Zaretskii, 2013/05/03
- Re: Some serious issues with the new -O option, Paul Smith, 2013/05/03
- Re: Some serious issues with the new -O option, Eli Zaretskii, 2013/05/03
- Re: Some serious issues with the new -O option, Paul Smith, 2013/05/03