jack@stevie.cs.unlv.edu (Jack Alexander) (12/29/89)
Hello: I have a need for a make-type program that will allow recompilations to be dependent on the changing of compiler definitions (i.e., "-DVERSIONB") The problem is that I have many megabytes of code that have to support many, many different versions of basically the same program. Because I want to keep the guts of the system the same, whereever a slight modification is needed for a particular version, I just make the code segment conditional using #ifdef's, #ifndef's, etc. However, when I change a compile variable, I don't want to re-compile every file (some directories may have 50 source files each), just the ones that actually reference the variable. Has anybody heard of any such program? Does anybody else need such a program? If the need is terrific, I may endeavor to hack it into gnu make. If I do this, I would appreciate any recommendations. -- Jack Alexander
silvert@cs.dal.ca (Bill Silvert) (12/29/89)
In article <1440@jimi.cs.unlv.edu> jack@jimi.cs.unlv.edu (Jack Alexander) writes: >I have a need for a make-type program that will allow recompilations >to be dependent on the changing of compiler definitions (i.e., "-DVERSIONB") >... However, when I change >a compile variable, I don't want to re-compile every file (some directories may >have 50 source files each), just the ones that actually reference the variable. It seems that this should be doable with existing forms of make. Arrange to set each define in a file (use `cat ...` to get the contents into the command line) and set up dependencies. Then when you edit the file "versionb" (containing just the line "-DVERSIONB") the appropriate files get remade. The dependencies can be set up either by hacking an existing dependency generator or by using greps. -- Bill Silvert, Habitat Ecology Division. Bedford Institute of Oceanography, Dartmouth, NS, Canada B2Y 4A2 UUCP: ...!{uunet,watmath}!dalcs!biomel!bill Internet: biomel@cs.dal.CA BITNET: bs%dalcs@dalac.BITNET
shenkin@cunixc.cc.columbia.edu (Peter S. Shenkin) (12/29/89)
In article <1440@jimi.cs.unlv.edu> jack@jimi.cs.unlv.edu (Jack Alexander) writes: >I have a need for a make-type program that will allow recompilations >to be dependent on the changing of compiler definitions (i.e., "-DVERSIONB") > ....when I change >a compile variable, I don't want to re-compile every file (some directories may >have 50 source files each), just the ones that actually reference the variable. How about this solution, using ordinary make. You write a shell script which does an fgrep on the .c (and/or .h) files, searching for the definition in question -- e.g., "VERSIONB" -- then "touch"es each file in which it is found. You have a special target in the make file which you invoke whenever you want to recompile everything that depends on this. This target first runs the script, then "make"s the program target. There are complications, but something like this ought to be doable; at worst, you'd need a separate target for each -D you expect to invoke from the commandline. For example, you could have target "VERSIONB:". Then, if you said "make -DVERSIONB VERSIONB" the VERSIONB: target would first do the fgrep on VERSIONB & touch, then make the program. You could even define a csh "alias makeD make -D\!* \!*" which would work, provided you only gave it a single -D. More elegant solutions would be necessary if you wanted to either use more than one -D at once or else have a single target that would work no matter what the -D, but you get the idea.... -P. -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixc.cc.columbia.edu(Internet) shenkin@cunixc(Bitnet)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/30/89)
You can sort of do this now. You can put the defines in a separate header file and have your main header file include them, setting dependencies for each source which must change, or you can make a dummy item which you touch when you change the define, then make objects depend on it. None of this is automatic, but it is portable. # these change when OS is redefined OSLIST = part2.o random.o report3.o # touch osdef.inc when the OS define is changed $(OSLIST):: osdef.inc I think a portable program to go through files and generate some list of defines used would be more useful to you and others. -- bill davidsen - sysop *IX BBS and Public Access UNIX davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen "Getting old is bad, but it beats the hell out of the alternative" -anon
rfinch@caldwr.UUCP (Ralph Finch) (12/30/89)
In article <1440@jimi.cs.unlv.edu>, jack@stevie.cs.unlv.edu (Jack Alexander) writes: > I have a need for a make-type program that will allow recompilations > to be dependent on the changing of compiler definitions (i.e., > "-DVERSIONB") > Has anybody heard of any such program? Does anybody else need such > a program? If the need is terrific, I may endeavor to hack it into > gnu make. The Sun make keeps track of the command used for each target, in a .make.state file. This will do just what you want, of course it's no good if you don't have a Sun. But it's so useful that for this one reason I haven't switched to Gnu make. I think it would be a very useful addition to Gnu make. -- Ralph Finch The opinions expressed herein are mine... ...ucbvax!ucdavis!caldwr!rfinch 916-445-0088
ludwiga@fbihh.UUCP (Arne Ludwig) (01/02/90)
jack@stevie.cs.unlv.edu (Jack Alexander) writes: >I have a need for a make-type program that will allow recompilations >to be dependent on the changing of compiler definitions (i.e., "-DVERSIONB") This is just one of the capabilities of the shape toolkit and the AFS (Attributed file system) that has been posted in comp.sources.unix Volume 19 some months ago. With shape, however, you can/must define the dependencies explicitly. AFS/Shape will also handle version control. (as in sccs or rather rcs) (This is the way the conditional recompilation is actually done!) Note that the CSU distribution is not a production release. For further info or newer releases read the README file in the dist. Example of a "Shapefile": # Parts Copyright (C) 1989, 1990 W. Koch, A. Lampen, A. Mahler, W. Obst, # and U. Pralle FOO = versionb # changing here will generate new version OBJECTS = file1.o file2.o prog : +$(FOO) $(OBJECTS) $(CC) $(CFLAGS) $(LDFLAGS) -o prog $(OBJECTS) #% VARIANT-SECTION vclass foo ::= (versiona, versionb, versionc) versiona: CFLAGS = -g -pg -DDEBUG versionb: CFLAGS = -O -DVERSIONB LDFLAGS = -s versionc: CC = gcc CFLAGS = -O -g -finline-functions -fkeep-inline-functions \ -fcombine-regs #% END-VARIANT-SECTION --- Arne Ludwig ludwig@fbihh.informatik.uni-hamburg.de tmpmbx!tchh!rrzbu!arne -- Arne Ludwig ludwig@fbihh.informatik.uni-hamburg.de tmpmbx!tchh!rrzbu!arne
guy@auspex.auspex.com (Guy Harris) (01/03/90)
>The Sun make keeps track of the command used for each target, in a >.make.state file. This will do just what you want, of course it's no >good if you don't have a Sun. (Actually, I've seen ads for what I remember as being a PC version of "make" that claims to be compatible with the Sun version; whether this includes the ".KEEP_STATE" target and corresponding file I don't know.) >But it's so useful that for this one reason I haven't switched to Gnu >make. I think it would be a very useful addition to Gnu make. I certainly like it as well, although it doesn't do exactly what the person wanted, i.e. keep track of which files actually use the #define in question and only rebuild those if the #define changes. Note, though, that it depends on changes to the compiler (preprocessor phase) and linker as well, so that whenever a file is #included or a library is linked in, it's recorded as being a file that the target depends on. You can't *just* change GNU Make, you'd have to change GCC as well. Sun "make" and "cpp"/"ld" use the environment variable SUNPRO_DEPENDENCIES to communicate; a sample run yielded the following environment variables (having a rule that ran "env"): KEEP_STATE= SUNPRO_DEPENDENCIES=/tmp/make.dependency.20693.0 all I don't know what KEEP_STATE is supposed to be; SUNPRO_DEPENDENCIES has what I believe is the pathname of a file into which the program is to dump the dependencies in question (presumably in Makefile form), but I don't know what the second token (the "all") does.
kcantrel@digi.UUCP (Keith Cantrell) (01/04/90)
In article <1440@jimi.cs.unlv.edu> jack@jimi.cs.unlv.edu (Jack Alexander) writes:
Jack>
Jack>Hello:
Jack>
Jack>I have a need for a make-type program that will allow recompilations
Jack>to be dependent on the changing of compiler definitions (i.e., "-DVERSIONB")
Jack>The problem is that I have many megabytes of code that have to support
Jack>many, many different versions of basically the same program. Because I
Jack>want to keep the guts of the system the same, whereever a slight
Jack>modification is needed for a particular version, I just make the code
Jack>segment conditional using #ifdef's, #ifndef's, etc. However, when I change
Jack>a compile variable, I don't want to re-compile every file (some directories may
Jack>have 50 source files each), just the ones that actually reference the variable.
Jack>
Jack>Has anybody heard of any such program? Does anybody else need such a program?
Jack>If the need is terrific, I may endeavor to hack it into gnu make. If I do
Jack>this, I would appreciate any recommendations.
Jack>
Jack>-- Jack Alexander
Yes, go out and buy an Apollo and use DSEE. It keeps up with not only the
version of source that goes into making an object, but all the command(s), and
options to the commands, as well.
Keith
-----------------------------------------------------------------------
Keith Cantrell Phones: hm: 214-492-1088
wk: 214-519-2399
USMAIL: EMAIL:
2100 Sonata Ln cantrell@attctc.DALLAS.TX.US
Carrollton TX 75007 or
...!attctc!digi!kcantrel
-----------------------------------------------------------------------woerz%leonardo@isaak.uucp (Dieter Woerz) (01/04/90)
In article <297@digi.UUCP> kcantrel@digi.UUCP (Keith Cantrell) writes: >In article <1440@jimi.cs.unlv.edu> jack@jimi.cs.unlv.edu (Jack Alexander) writes: Jack> Jack>Hello: Jack> Jack>I have a need for a make-type program that will allow recompilations Jack>to be dependent on the changing of compiler definitions (i.e., "-DVERSIONB") Jack>The problem is that I have many megabytes of code that have to support Jack>many, many different versions of basically the same program. Because I Jack>want to keep the guts of the system the same, whereever a slight Jack>modification is needed for a particular version, I just make the code Jack>segment conditional using #ifdef's, #ifndef's, etc. However, when I change Jack>a compile variable, I don't want to re-compile every file (some directories may Jack>have 50 source files each), just the ones that actually reference the variable. Jack> Jack>Has anybody heard of any such program? Does anybody else need such a program? Jack>If the need is terrific, I may endeavor to hack it into gnu make. If I do Jack>this, I would appreciate any recommendations. Jack> Jack>-- Jack Alexander Keith>Yes, go out and buy an Apollo and use DSEE. It keeps up with not only the Keith>version of source that goes into making an object, but all the command(s), and Keith>options to the commands, as well. If you can do this on a Sun, use the normal make coming with it. This make can keep track of the commands executed to build the targets. So if you change one of the Flags on one of the commands, make knows, what files to recompile. If you choose your make macros carefully, you only compile and link, what is needed to recompile. Hope this helps. Dieter Woerz ISA GmbH, Azenbergstr. 35 D-7000 Stuttgart-1 W-Germany UUCP: {pyramid!iaoobel,uunet!unido}!isaak!woerz BITNET/EARN: woerz@ds0iff5
guy@auspex.auspex.com (Guy Harris) (01/05/90)
>Yes, go out and buy an Apollo and use DSEE. It keeps up with not only the >version of source that goes into making an object, but all the command(s), and >options to the commands, as well. Yes, and he can also buy a Sun (or, presumably, Solbourne) and, if it's running 4.x or 3.x with the "SunPro make" he can get that as well from "make" if he uses ".KEEP_STATE", but it's possible that he's not in a position to throw out existing machines and cut over entirely to a new one.... 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: 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?
dricejb@drilex.UUCP (Craig Jackson drilex1) (01/08/90)
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}
axel@coma.UUCP (Axel Mahler) (01/10/90)
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
jona@moss.ATT.COM (Jon M. Allingham) (01/12/90)
In article <1440@jimi.cs.unlv.edu> jack@jimi.cs.unlv.edu (Jack Alexander) writes:
]
] Hello:
]
] I have a need for a make-type program that will allow recompilations
] to be dependent on the changing of compiler definitions (i.e., "-DVERSIONB")
] The problem is that I have many megabytes of code that have to support
] many, many different versions of basically the same program. Because I
] want to keep the guts of the system the same, whereever a slight
] modification is needed for a particular version, I just make the code
] segment conditional using #ifdef's, #ifndef's, etc. However, when I change
] a compile variable, I don't want to re-compile every file (some directories may
] have 50 source files each), just the ones that actually reference the variable.
]
] Has anybody heard of any such program? Does anybody else need such a program?
] If the need is terrific, I may endeavor to hack it into gnu make. If I do
] this, I would appreciate any recommendations.
]
] -- Jack Alexander
AT&T has a new version of make (nmake) that does exactly that sort of
thing. You can set variables in the makefile, specify that certain
source files depend on them and then the "cc" line will put in the
-Dvar=val. It maintains all info in a state file and recompiles the
necessary files when needed. Changing the rule will also cause the
correct files to be recompiled.
It also does auto dependency generation, i.e. it determines
automagically what header files are #included (even does nested
includes) and allows make variables to be specified as "SCAN"
variables, in which case it will scan source files (including #include
files) for use of that symbol and include its value as a -Dvar=val.
It also has full support for viewpathing which is really a must for
large projects. Viewpathing allows you to have a "background (or
`official' node" containing the entire project directory structure and
one or more "development nodes" which contain some piece corresponding
to the official structure. This development node is overlayed on the
official node and any files in it supercede the official stuff. Any
files not found in a development node are take from the official node.
Pretty slick actually.
Makefiles are also preprocessed with cpp and there is a lot of support
for conditionals inside the makefile. Setting command line flags will
change the conditionals. Between getting rid of the explicity
dependencies and adding more power to make, nmake makefiles are
significantly smaller and more powerful than their make counterparts.
It also works on many different machines, the only real requirement is
that the C compiler allow an alternate cpp be used since the standard
cpp's header search rules break viewpathing.
The only problem I can forsee is availability outside AT&T. As I am
only a happy user I really don't know what the status is.
If you are interested in finding out more or in determining
availability contact nmake@mozart.ATT.COM or perhaps
steve@mozart.ATT.COM.
My 2 cents on adding features like this to existing makes:
Some stuff can probably be added without too much grief, but you really
are looking at some fundamental changes in the way make works. I know
that Nmake was entirely new code and not a re-hack of make and it still
is a monster program.
----
Jon M. Allingham (201)386-3637 AT&T Bell Laboratories (Whippany,NJ)
{clyde}!moss!jona WH 14D-339
"To those of us with real understanding, dancing is the only pure art form"
-Snoopy
--
----
Jon M. Allingham (201)386-3637 AT&T Bell Laboratories (Whippany,NJ)
{clyde}!moss!jona WH 14D-339