[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: simpler way to do multi-arch builds?
From: |
Robert P. J. Day |
Subject: |
Re: simpler way to do multi-arch builds? |
Date: |
Tue, 29 Mar 2005 16:47:04 -0500 (EST) |
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