Auto-configuring software -- potential problems

[R. Curtis Jackson]

I agree with the original author of the referenced article; here is
one 'safe' way to go about it.  I use as an example a package of mine
to build a product called 'pds3':

pds3 comes with a makefile template (pds3.mk), and a makefile localizer
(pds3local.l) written using lex(1).  When you get the package, if you
type 'make' you get (of course) nothing because there is nothing called
'[Mm]akefile'.  To localize, the READ_ME file tells you to type
'make local'.  This lex's and compiles the localizer, runs the localizer,
pds3local.  pds3local uses pds3.mk and user input (in the form of answers
to questions like "Path to directory where you wish executable to reside?")
and outputs an edited/filled-in version of pds3.mk called 'makefile'.
It then tells the user to type 'make' to make the package (usually I have
an 'install' rule, but for these customers that was automatic).  Here
is the portion of the original pds3.mk that has to do with localizing:


local: pds3local
	pds3local
	- at echo "\n\nMakefile has been localized; please type 'make' again"
	- at echo "to make $(XMODULE); it can run in background this time.\n"

pds3local: pds3local.c
	$(CC) $(CFLAGS) -DMAKENAME="\"%Z% %P% %I% %G%\"" -o pds3local pds3local.c -ll


The %Z% %P% %I% %G%, of course, would be expanded by SCCS....

After localization, the 'local' rule in 'makefile' looks like this:

local:
	- at echo "\nTo re-localize, do the following:\n"
	- at echo "\tmake -f pds3.mk local\n"

No original source is modified.

A couple of other hints you might want to take advantage of:

a) Put in a '-v' (or '-V') switch in every program that will give
a short one-line functional name for the program and end with release
and version info, like this:

PDS Section 3 Builder (pds3) -- Version 2 released 9/25/84

This can be easily accomplished on Unix by using SCCS to store
your code and having %R% and %G% in place of the version number
and date above -- every time you release a new version (say, version X),
just do a 'get -e -rX s.foo.h', and delta it back (it will go back
into SCCS as X.1).

b) Do not put ANY hardwired includes (except system includes) or
pathnames in your programs; put it all in your makefile and use
cpp(1)'s -D option to define them from the makefile and !!USE MAKE
VARIABLES FOR EVERYTHING!!; this means you can quickly and easily
override them from the make command-line.

c) Use SCCS to your advantage -- be sure to include some string
of keywords (in the files on our project, it is "%Z% %P% %I% %G%",
which expands to "@(#) <pathname-of-SCCS-file> <SID> <date-last-delta>")
in every file you have.  Use:
char *FILENAME = "%Z% %P% %I% %G%";
(where FILENAME is the filename in CAPS (to avoid load conflicts))
for program source.  For include files included by multiple modules,
have one designated 'command' module that defines a symbol (I use ZPIG)
and have the include file contain:
# ifdef ZPIG
char *INCFILENAME = "%Z% %P% %I% %G%";
# endif
In the same 'command' module, have something that looks like this:
char *MAKEFILE = ZPIGMK;
and have your makefile use:
-DZPIGMK="\"%Z% %P% %I% %G%\""
as one of the compilation switches.  By various tricks such as these,
you can get an executable that you can do a what(1) on and get something
like this:
$ what /emsp/dev/bin/gus
/emsp/dev/bin/gus:
	 /emsp/cmf/emsp/proto/sccs/C/as/asgu/s.asguasc.md 2.2 10/8/84
	 /proto/sccs/C/as/asgc/s.asgcmystr.c 2.1 10/5/84
	 /emsp/cmf/emsp/proto/sccs/C/as/asgu/s.asguau.y 2.2 10/7/84
	 /emsp/cmf/emsp/proto/sccs/C/as/asgu/s.asgucs.y 2.4 10/9/84
	 /emsp/cmf/emsp/proto/sccs/C/as/asgu/s.asgups.y 2.2 10/7/84
	 /emsp/cmf/emsp/proto/sccs/C/as/asgu/s.asgul.l 2.3 10/7/84
	 /emsp/cmf/emsp/proto/sccs/C/as/asgu/s.asgu.c 2.6 10/9/84
	 /proto/sccs/C/as/asgc/s.asgc.mk 2.2 10/7/84
	 /emsp/cmf/emsp/proto/sccs/C/as/asgu/s.asgu.md 2.1 10/5/84
	 /proto/sccs/C/as/asgc/s.asgcascfrm.l 2.1 10/5/84
	 /proto/sccs/C/as/asgc/s.asgclk.cf 2.1 10/5/84
	 /emsp/cmf/emsp/proto/sccs/C/as/asgu/s.asgu.h 2.3 10/7/84
	 /proto/sccs/C/as/asgc/s.asgcmystr.h 2.1 10/5/84
$

Put this list into a file (I call mine for gus 'asgu.sl', for S-list)
and put it under SCCS with a comment each delta like 'Version 3' and
you will suddenly have the ability to:

1) Run (or have a remote user run!!) one command (<prog> -v) to tell
him/her what version s/he is using.
2) If you have incremental releases between official versions, you
can now do a what(1) on any executable and see exactly what it is
made up of.
3) Return to any version, no matter how old, with practically no
effort.


Enough rambling for one night!!  Thanks for your time, and I hope
some of this has been of some help,

-- 
The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
			...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj