Using targets to make subdirectories is problematic, imho, since the timestamps on the directory don't have any particular meaning. This is a case of recursive maake being harmful.
If it was me, the dependency would be on the .a file, not on the directory. all: $(TARGETS) Target1: adir/lib1.a bdir/lib2.a ...... adir1/lib1.a: cd lib1 && make Etc. At least this seem to be about dependencies where the other form is basically a script that says do x,y,z in precisely my chosen order. One could write it better in bash than make. Regards, Tim On May 31, 2012 6:50 AM, "David Warme" <invalid.nore...@gnu.org> wrote: > 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 >
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make