Re: Some serious issues with the new -O option

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Fri, 03 May 2013 09:08:27 -0400
> 
> You're concentrating on the one recursive make target and saying
> "this doesn't follow the rule", while I'm concentrating on all
> targets in the sub-make and saying "let's make sure all of these
> follow the rule" (that their output is shown as soon as that target
> is complete).  Recursive make targets are merely artifacts of the
> build.  Users don't care about them; they're just used by makefile
> authors to organize things.  If the makefile author rewrote the
> makefiles to be non-recursive, users wouldn't notice at all.

Sorry, I don't understand this way of reasoning at all.  Maybe we are
talking about different things.  Let me try again.

Consider a target like this:

foo: ....
        prepare something
        $(MAKE) -C subdir doit
        touch foo-done

Is this a legitimate and good use of recursive Make?  Should -O cater
to this use case?  Or is this use case rare (or even bad practice), so
much so that the _default_ mode of -O is allowed to confuse the heck
out of the user, who will see the output of the subdir job _before_
she sees the output of preparations for that subdir job?

If the reason for exempting recursive Make invocations from -Otarget
is that you want it to cover a different use case, like this:

foo: ...
        $(MAKE) -C subdir doit

then how about if this exemption will only be applied if the recipe
has a single command?

If the single-command-in-recursive-invocation is _not_ the use case
which -Otarget is optimized for, then what use case is?

IOW, what is the "ideal" Makefile where -Otarget doesn't have any
downsides whatsoever?