> From: Paul Smith <[email protected]>
> Cc: [email protected], [email protected]
> 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?
_______________________________________________
Bug-make mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-make
