Generating a demo version from production code
Daniel Mocsny
dmocsny at minerva.che.uc.edu
Sun Nov 18 01:37:54 AEST 1990
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 at minerva.che.uc.edu Dept. of Chemical Engng. M.L. 171
dmocsny at uceng.uc.edu University of Cincinnati
513/751-6824 (home) 513/556-2007 (lab) Cincinnati, Ohio 45221-0171
More information about the Comp.lang.c
mailing list