Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!unido!tub!coma!axel
From: axel@coma.UUCP (Axel Mahler)
Newsgroups: comp.sources.d
Subject: Re: Looking for a make version to better support software versions
Message-ID: <676@coma.UUCP>
Date: 9 Jan 90 21:05:01 GMT
References: <1440@jimi.cs.unlv.edu> <297@digi.UUCP> <2792@auspex.auspex.com> <7299@drilex.UUCP>
Reply-To: axel@coma.UUCP (Axel Mahler)
Organization: Technical University of Berlin, Germany
Lines: 88

In article <7299@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes:
>In article <2792@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>
>>In addition, he didn't just want to have the system keep track of the
>>commands (which includes the options, at least in the way the Sun "make"
>>thinks of it) used to build an object, he wanted it to *only* remake
>>those modules that actually *use* the value of a #define from the
>>command line:
>>
>(The original poster, evidently named Jack, wrote:)
>>Jack>However, when I change a compile variable, I don't want to
>>Jack>re-compile every file (some directories may have 50 source
>>Jack>files each), just the ones that actually reference the variable.
>>
>>which the Sun "make" won't do automatically - will DSEE do that?
>
>None of the configuration control packages on the market that I know
>of will do this.  (However, I haven't seen DSEE for about two years.)
>
Shape can handle this problem in a rather straightforward manner. It is 
possible to additively define "variants" on a per-dependency-line-basis.
A "Shapefile" supporting this technique could look something like:

#% VARIANT-SECTION

variant-1:
	CFLAGS = -DFOO

variant-2:
	CFLAGS = -DOOPS -Dint=long

variant-3:
	CFLAGS = -DBAR

#% END-VARIANT-SECTION

a: x.c y.c z.c
	$(CC) -o a x.o y.o z.o

x.c: +variant-1 +variant-3 x.h

y.c: +variant-2

z.c: +variant-1 +variant-2 +variant-3 bla.h

# End of sample-Shapefile

In the given example, "x.c" would be compiled with:
	"cc -c -DFOO -DBAR x.c"

"y.c" would be compiled with:
	"cc -c -DOOPS -Dint=long y.c"

and "z.c" would be compiled with:
	"cc -c -DFOO -DOOPS -Dint=long -DBAR z.c"

As shape keeps track of which .o-objects are produced with which 
compiler switches (actually shape allows to declare derived
objects dependent on any macro(-value)), it would only recompile the
source modules that actually depend on a particular switch setting.
If - in the given example - the "variant-1" defintion is changed 
(let's say to "CFLAGS = -DFOOBAR -DXYZZY"), only "x.o" and "z.o" would
be re-derived. 

To use this technique in a largish project requires a good deal of
"Shapefile-Engineering" though.

Shape and the other tools of the "Shapetools-Toolkit" provide a lot
more functionality than the described example. The first release of
the toolkit is approx. one year old. It was distributed via 
comp.sources.unix. It is free software. 

The new release is almost finished (it was supposed to be ready by
Nov. 30th '89, but fixing a clean release was more work than we
expected :-( ).  It will run on almost any decent UNIX platform (BSD
and SysV).

In case you're interested, stay tuned to "comp.software-eng" for the
release announcement.

Axel.
_____

-- 
Axel Mahler, Tech.Univ. Berlin

UUCP: axel@coma.uucp (unido!coma!axel)
BITNET: axel@db0tui62.bitnet