Follow-up Comment #43, bug #17873 (project make): Another scenario wherein sequential processing of dependencies is useful:
all: subdirs $(TARGETS) subdirs: (cd dir1 && make) (cd dir2 && make) and the $(TARGETS) depend upon libraries (.a files) that are made by dir1 and/or dir2. If you do this with make -j, then make immediately evaluates each $(TARGET) before the "make subdirs" gets a chance to touch/update any of the .a files. Make therefore decides that nothing is out of date regarding the link steps, and so each link node in the build tree gets retired without doing anything. Issuing a second "make" command later, however, causes it to re-link the $(TARGETS) because now one or more .a files is newer than the corresponding $(TARGETS). It is a pain to have to introduce time-stamp-files just to force the links to wait until after the "subdirs" has finished. Phony targets (e.g., install, subdirs, etc.) often tend to involve recipes that need to be done serially -- especially when stringing several together as dependencies of another phony target. The previous example of: reinstall: uninstall install is precisely this sort of "dependency encoded sequential recipe". The syntax is negotiable. But so long as -j exists, there will be a need to specify series/parallel constraints within dependency lists. The alternatives (e.g., time stamp files) are simply too horrible to contemplate. Some would argue that the antidote to the above scenario is this: $(TARGETS) : subdirs But this gets rid of the ability to do "make target1" without forcing make to also do the "subdirs". In some cases the developer knows that nothing in the huge sub-tree of subdirs has changed and all he/she needs to do is re-link the local executable. The $(TARGETS) : subdirs kludge effectively eliminates this capability. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?17873> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make