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