Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!drilex!dricejb
From: dricejb@drilex.UUCP (Craig Jackson drilex1)
Newsgroups: comp.sources.d
Subject: Re: Looking for a make version to better support software versions
Message-ID: <7299@drilex.UUCP>
Date: 7 Jan 90 16:24:53 GMT
References: <1440@jimi.cs.unlv.edu> <297@digi.UUCP> <2792@auspex.auspex.com>
Organization: DRI/McGraw-Hill, Lexington, MA
Lines: 32

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.)

There was some research about this kind of thing at GTE Labs in Waltham, Ma,
described at a conference a few years ago.  This sort of thing really begins
to need a 'program informaion database', where significant results of each
compilation (possibly including, but not limited to, the parse tree) are
kept around for use by other tools.  'Keep_state' hacks are a beginning, but
to know about define usage, etc, you want to go farther.  (Once you've done
define usage, the next job is to bring up automatically into the editor
all calls of the subroutine whose calling sequence you have redefined.
This is possible with existing tools, to some extent.  So is the problem
with defines.)
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}