Noel Yap wrote: > > IME, it's best to have a GNUmakefile in each directory (so anyone can do a > gmake > within any directory) and a, say, GNUprivate.mk file within each directory > (that > contains the non-common stuff).
The problem of recursing becomes apparent when there are inter-directory dependencies. Did you ever wish, while writing a makefile, that you had at hand all the dependencies already specified for another directory? In facts, writing recursively is easier and there is much more experience with it than with single makefile builds. > I've seen two philosophies on this: > 1. gmake within any directory will build the entire project > 2. gmake within any directory will build that directory and > any subdirectories (a la recursive make) > > I personally lean towards the second philosophy me too. > which means that each GNUmakefile needs to include its corresponding > GNUprivate.mk and its subdirectories' GNUprivate.mk's. AFAIK, there is no recognized standard for writing these. Of course there must be agreed variable naming conventions. However, should one code each file name with a variable prefix in front of it? E.g., TARGETS += $(PATH_TO_HERE)my_target $(PATH_TO_HERE)my_target : $(PATH_TO_HERE)my_obj1 $(PATH_TO_HERE)my_obj2 where PATH_TO_HERE is set to "this_subdir/" by the parent, or else is empty. That contradicts rules 3 and 4 in <http://make.paulandlesley.org/rules.html>, but there are no directives such as `include_and_cd' or even just `cd'. There is vpath, but how do I know that a source file named just like mine will never appear in some upper directory? Furthermore, many rules work just smoothly when issued from the proper directory. I often write `$(MAKE) -C' when all I wanted to say was `cd'. > To minimize maintenance on GNUmakefile, a function is used that'll just > shell out and execute a "find . -name GNUprivate.mk". Otherwise, each GNUprivate.mk may include its subdirectories' GNUprivate.mk's. The $(wildcard) fuction may come handy for this. > HTH, > Noel > > Robert P. J. Day wrote: > > > On Sat, 15 Jan 2005, Alessandro Vesely wrote: > > > > > >>"Robert P. J. Day" wrote: > >> > >>>[...] > >>>and it was just yesterday that it suddenly dawned on me how to make > >>>this much simpler, and only after i started redesigning the structure > >>>did it occur to me that this might be what miller's paper might be > >>>talking about. > >> > >>It is not. Peter Miller's emphasis is about make being able to > >>traverse the whole dependency tree the way it reckons, rather that > >>traversing it a sub-tree at a time in the order dictated by the > >>top-level makefile without ever being able to see the whole tree at > >>once. E.g. using `include' rather than `$(MAKE)'. > > > > > > yes, i see what you mean. i hadn't actually finished the paper, but i > > thought i could see what he was getting at. > > > > still, i think philosophically there's some common ground -- i'm > > seeing a definite advantage in taking control of the lower-level parts > > of the build process and pulling them back to the top of the tree so i > > can control the entire process all at the top level (even to the > > extent, as i described in my next posting, of controlling build > > options of lower levels at the very top). > > > > i'll think on this some more. thanks for the feedback. > > > > rday > > > > > > _______________________________________________ > > Help-make mailing list > > [email protected] > > http://lists.gnu.org/mailman/listinfo/help-make _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
