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" <[email protected]> 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
> [email protected]
> https://lists.gnu.org/mailman/listinfo/bug-make
>
_______________________________________________
Bug-make mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-make
