If you want to call a third party Makefile, you've got no choice. You
already have a recursive make, parallel or not.
I have probably incorrectly expressed myself. I don't want to *call* a third party Makefile.
I am just using it, and want to improve it, but I can't afford to spend a lot of time exposing all of the actual dependencies (there would really be a huge number of them). So, my only alternative is to introduce recursive calls to make, which I dislike.
Specifically, we are working on a compiler (Open64), and as we are not the official maintainers, we don't want to diverge to much from the official sources. Yet, we want to improve build time, while focusing on our activity (compiler development), not on the build system.
BTW your example won't build those two targets in parallel, even if parallel
compilation is possible. I'd consider the way you've done this to be bad
practice. Instead I'd have
all: all-subdir all-local
.PHONY all-subdir all-local
all-subdir:
$(MAKE) <whatever>
all-local:
$(MAKE) <whatever2>
If I wanted to make it clear that these had to be serialized, I'd just add
all-local: all-subdir
I find that prettier than the .WAIT syntax. Beauty is in the eye of the
beholder in this case, but what I like about the above method is that it
does what you are talking about right now.
Consider a variant of this; the original Makefile is:
all: one two three
one: some-deps1
cmds1
two: some-deps2
cmds2
three: some-deps3
cmds3
Now, I call "make -j" and discover that one two and three should be ran sequentially, I suppose you will suggest to have two depend on one and three depend on two.
But then, I would like that when I call "make two", only two is rebuilt, not "one".
Inserting .WAIT in the all target solves this issue, without calling make recursively.
Christophe.