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.
_______________________________________________ Help-make mailing list Help-make@gnu.org http://lists.gnu.org/mailman/listinfo/help-make
