On Mon, 21 Mar 2005, Paul D. Smith wrote: > There are simpler ways to do it but I don't know that anyone has written > them up in a document like that. > > > There are many folks (including myself) who've developed build > systems which are 100% (insofar as that's possible) data driven. > That is, individual makefiles do nothing but define variables: they > never define any rules. Then, more advanced features like call and > eval are used to actually do the work. So an individual makefile > might say something like (this syntax is basically directly from a > system I use here): > > PROGRAMS = foo > LIBRARIES = bar > > foo_SRCS = foo.c jar.cc baz.f > foo_LIBS = f77 > foo_CPPFLAGS = -I../include > > bar_LIBSRCS = bar.c biz.c boz.c > bar_SOVERSION = 4.0 > bar_CPPFLAGS = -I../include -DLIBBAR > > jar.o_FLAGS = -O3 > > > Speaking personally I've gotten away from the philosophy of that > multi-arch paper, of using VPATH, etc. etc. It relies an a few > "tricky bits" which are closer to "hacks", it doesn't fit will with > non-recursive make environments, etc. Its main advantage is and has > always been that makefiles are easier to write and read. Now, > that's a very significant advantage, of course, and not to be > dismissed lightly at all.
when i first saw that approach, i thought it was a bit hacky as well, but there's one feature about it i like and that is its ability to be incorporated into a current build structure without hacking that build structure. given that the standard makefile template has the form: ifeq (,$(filter _%,$(notdir $(CURDIR)))) include target.mk else #----- End Boilerplate VPATH = $(SRCDIR) Normal makefile rules here <-- crucial bit here #----- Begin Boilerplate endif that means (as i've been reading it) that i can "wrap" this feature around a current makefile just using an "include" at that crucial point. i've already seen the other approach where rules are generated in which all file references are prefixed with $(OUTPUTDIR) or something like that and, even with the hackiness, i prefer the first technique just because the makefiles still look familiar to others. rday _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
