[820] in Release_Engineering
Re: CAKE
geer@ATHENA.MIT.EDU (geer@ATHENA.MIT.EDU)
Mon Mar 6 09:32:50 1989
Date: 5 Mar 89 16:10:59 GMT
From: mcvax!ukc!harrier.ukc.ac.uk!mtr@uunet.uu.net (M.T.Russell)
Subject: Re: CAKE
To: xpert@expo.lcs.mit.edu
In article <8903040041.aa11101@SPARK.BRL.MIL> mike@BRL.MIL (Mike Muuss) writes:
>With CAKE, we maintain binaries for six different kinds of machines
>from one set of sources, via NFS (Gould, Sun, Alliant, SGI 3d, SGI 4d,
>Convex). It was this feature that caused us to abandon Make, and
>seek another tool: CAKE.
You can do this quite neatly with plain old make. I posted an article
describing how to do this a while ago, but got no response. Here it
is again (if there is some fatal flaw with this, someone please tell
me to shut up :-)).
We have a scheme for building binaries for multiple architectures in a
single source tree which I haven't seen described elsewhere. We have
a make variable (M) set to a name for the architecture/OS combination,
which is then used in the makefile to name the architecture specific
object (.o) files and binaries. Makefiles look like this:
.SUFFIXES: .$Mo
.c.$Mo:
$(CC) -c $(CFLAGS) $*.c && mv -f $*.o $*.$Mo
OBJS = bar.$Mo baz.$Mo
foo: $Mfoo
$Mfoo: $(OBJS)
$(CC) -o $@ $(OBJS)
So if M is set to "sun3_sunos4_", then bar.sun3_sunos4_o and baz.sun3_sunos4_o
are linked to build sun3_sunos4_foo.
This scheme has several advantages over the shadow tree of symlinks method:
- you always get the right binary for the right architecture
just by typing make
- binaries for multiple architectures can exist simultaneously in the
same source directory
- all you have to do to add a new architecture or OS version is
to define a new name for it
- no shadow tree of symlinks to build and maintain
Of course with an existing source tree it has the disadvantage that
you'd have to hack all the makefiles - we only use it for our own
projects. On the other hand, I'd love to see something like this
in the R4 makefiles - presumably imake makes this kind of addition easy.
This scheme is also useful whenever you want distinct sets of .o files.
Common examples are:
make "M=${M}gcc_" "CC=gcc" # build a version with gcc
make "M=${M}gprof_" "CFLAGS=-pg" # build a profiled version
One problem is that you can't have two makes running simultaneously
on two different architectures as the intermediate .o files can clash.
What I'd like to write for the compilation rule is
.c.$Mo:
$(CC) -c $(CFLAGS) -o $*.$Mo $*.c
but unfortunately the standard C compilers don't allow -o with -c.
Gcc *does* allow this; when it takes over the world we will start
using the above rule.
M is set in the environment, usually via .login. Locally we have
a machinetype command, and the line
setenv M `machinetype`
in .login.
If your version of make doesn't import environment variables, you have to
install a wrapper, e.g.
#! /bin/sh
exec /bin/make ${1+"$@"} "M=$M"
(the ${1+"$@"} is a workaround for broken versions of sh that don't
implement "$@" correctly).
We've been using this scheme locally to maintain several medium sized
projects (10-25K lines) across Sun 3s running 3.5 and 4.0, a Sun 386,
an HLH Orion Clipper, and VAXen running Ultrix and 4.3BSD. It works well.
Mark Russell
mtr@ukc.ac.uk
