dmocsny@minerva.che.uc.edu (Daniel Mocsny) (11/17/90)
I need to create a demonstration version of a C program. This demonstration program will preserve the user-interface and screen-handling of the original, but will disable certain aspects of the original program's function, such as the ability to vary built-in data by editing, and writing/reading data files. I would like to maintain one set of sources from which I can generate either a demo or a production version by using a different target in the makefile. To communicate between the makefile and compiler, I add a "-DDEMO" flag to the cc command line after the demo target. The sources contain, at judicious locations, preprocessor directives of the form: #ifdef DEMO ... (fake it) #else ... (do the real thing) #endif So far this is pretty straightforward. So what's my question? Well... 1. Does this sound like a reasonable way to keep demo and production versions of a program synchronized? If anyone has any specific suggestions on how to prepare demonstration versions of a program, I would like to hear them now before I get into this any deeper. 2. When I have two different targets in my makefile starting with the same sources, I get what I might call "object-file name collision". I.e., compiling a source program smurf.c produces an object file smurf.o for both demo and non-demo versions. If I make a demo from scratch, I have a bunch of demo-ized object files hanging around. Then if I edit one source file, and try to make a production version, only one object file gets updated, because make doesn't know that the seemingly up-to-date objects don't correspond to the production target. What is the elegant way around this problem? I can imagine putting cp commands in the makefile to make copies of the sources and/or objects at make time, and then defining dependencies to tell make when to update the copies. Since I can't find a compiler flag that can create an object file with the name demo_smurf.o from a source named smurf.c, is that what I have to do? -- Dan Mocsny Snail: Internet: dmocsny@minerva.che.uc.edu Dept. of Chemical Engng. M.L. 171 dmocsny@uceng.uc.edu University of Cincinnati 513/751-6824 (home) 513/556-2007 (lab) Cincinnati, Ohio 45221-0171
karl@ima.isc.com (Karl Heuer) (11/18/90)
In article <6734@uceng.UC.EDU> dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes: >Since I can't find a compiler flag that can create an object file with the >name demo_smurf.o from a source named smurf.c, is that what I have to do? No doubt someone is about to recommend "cc -c smurf.c -o demo_smurf.o" without realizing that it's a non-portable Berkeleyism. Yes, I recommend you use "cc -c smurf.c && mv smurf.o demo_smurf.o". Since this destroys any "smurf.o" you already have, you may want to consider making the other target with "cc -c smurf.c && mv smurf.o real_smurf.o" so there's no "smurf.o" target. Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
lerman@stpstn.UUCP (Ken Lerman) (11/19/90)
In article <6734@uceng.UC.EDU> dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes:
[...]
->I need to create a demonstration version of a C program. This demonstration
->program will preserve the user-interface and screen-handling of the
->original, but will disable certain aspects of the original program's
->function, such as the ability to vary built-in data by editing, and
->writing/reading data files.
[...]
->--
->Dan Mocsny Snail:
->Internet: dmocsny@minerva.che.uc.edu Dept. of Chemical Engng. M.L. 171
-> dmocsny@uceng.uc.edu University of Cincinnati
->513/751-6824 (home) 513/556-2007 (lab) Cincinnati, Ohio 45221-0171
We add a subdirectory called demo to each directory. Then have your
makefile first create the demo version of a .o, then move it to the
demo subdirectory, and then create the non-demo version. (In our
case, we have debug, non-debug versions, and shared-library versions
of some of our code.)
The only disadvantage we find in this is that when we are in a major
debug cycle, we always make both versions and that takes a little
longer. Of course, we could have multiple targets to solve this problem.
Kenengbert@cs.vu.nl (Engbert Gerrit IJff) (11/20/90)
In article <1990Nov18.004032.10424@dirtydog.ima.isc.com>, karl@ima.isc.com (Karl Heuer) writes: ) In article <6734@uceng.UC.EDU> dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes: ) >Since I can't find a compiler flag that can create an object file with the ) >name demo_smurf.o from a source named smurf.c, is that what I have to do? ) ) No doubt someone is about to recommend "cc -c smurf.c -o demo_smurf.o" without ) realizing that it's a non-portable Berkeleyism. Yes, I recommend you use ) "cc -c smurf.c && mv smurf.o demo_smurf.o". Since this destroys any "smurf.o" ) you already have, you may want to consider making the other target with ) "cc -c smurf.c && mv smurf.o real_smurf.o" so there's no "smurf.o" target. ) ) Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint The other way to achieve your goal, when you are on a filesystem that knows of directories and multiple links is to have a subdirectory DEMO in which all the .h and .c files are just links to file with the same name in the real directory. (and also for the makefile) If you then go into your DEMO directory and do make -DDEMO you will get demo versions for your .o files that do not collide with the REAL .o files. The only thing you have to take care of is that you have ALL your .c files linked into the DEMO directory. Bert
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (11/22/90)
In article <6734@uceng.UC.EDU> dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes:
->I need to create a demonstration version of a C program. This demonstration
->program will preserve the user-interface and screen-handling of the
There's a fairly simple way of compiling several versions of a program
without interference. I've tried this under both 4.3 BSD and V.3 UNIX.
The idea is that you have three directories:
$PROG/ -- holds the sources
$PROG/production/ -- where the production version gets built
$PROG/demo/ -- where the demo version gets built.
In your Makefile, you have entries like
foo.o: ../foo.c
cc -c $(CFLAGS) ../foo.c
(well, that's the effect you want to generate). Then
cd $PROG/production
make -f ../Makefile CFLAGS=-Udemo program
will make the production/program version, and
cd $PROG/demo
make -f ../Makefile CFLAGS=-Ddemo program
will make the demo/program version. This relies on cc -c $DIR/$BASE.c
producing a $BASE.o file in the current directory, not in $DIR, but as
I say, I tried this in something claiming to be System V as well as in
something claiming to be BSD. Something like this may work with other
systems.
A UNIX-specific technique is to use links, so that each of the demo/
and production/ directories _thinks_ it has a copy of the sources, but
is in fact sharing the master copy.
--
I am not now and never have been a member of Mensa. -- Ariadne.