Re: simpler way to do multi-arch builds?

[Robert P. J. Day]

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