mike@BRL.MIL (Mike Muuss) (03/04/89)
In the X community, the topic of alternatives to Imake has come up again, and I figured that I would at least mention CAKE. CAKE is dubbed a "5th generation Make", because it uses pattern matching to fire it's rules, rather than just simple suffix transformations like Make uses. It also pre-processes scripts with CPP, like Imake. 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. We obtained CAKE from "net.sources" a long time ago; if anyone would like to experiment with it, feel free to obtain it via anonymous FTP from vgr.brl.mil: -r--r--r-- 1 mike 33050 Mar 4 00:29 arch/brl-cake-example.shar -r--r--r-- 1 mike 491520 Mar 4 00:27 arch/cake.tar -r--r--r-- 1 mike 182117 Mar 4 00:33 arch/cake.tar.Z The example file shows how we manage the BRL-CAD source & binary trees. Best, -Mike
mtr@ukc.ac.uk (M.T.Russell) (03/06/89)
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