From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: SAS/C 6.1 and GSTs (was Re: SAS 6.1 and IDIR problems
Originator: walker@twix.unx.sas.com
Date: Thu, 17 Dec 1992 14:13:16 GMT
Distribution: inet
Organization: SAS Institute Inc.


In article <1992Dec16.145012.6828@polaris.utu.fi>, sutela@polaris.utu.fi (Kari Sutela) writes:
|> Just use a Makefile (or smkfile).  Gather all your include-directives
|> in one file (or a set of files, if you prefer) --- let's call it
|> whatever.h --- and #include this file in your source file(s)
|> (whatever.c):

This is indeed a good technique, but I have two or three small points 
that will make it even better, see below:

|> # A sample Makefile
|> 
|> PROJECT=whatever
|> CFLAGS=GST $(PROJECT).gst

I never use a CFLAGS any more for something that I always want to be
on.  I would put this option in the SCOPTIONS file.  Note that if
you specify both MAKEGST and GST, the GST option is ignored!  Also,
if you have complete different option SETS, you can use the 
WITH <filename> option on the SC command instead of relying on
the scoptions file.

|> 
|> $(PROJECT): $(PROJECT).o
|> 	slink LIB:c.o $(PROJECT).o LIB LIB:sc.lib LIB:amiga.lib

There is really no reason to use slink now for most links.  If you
change your math options, you'll need to change your link libraries
in this method.  I suggest using the following instead:

   sc link $(PROJECT).o

This has the additional advantage that other linker options can be
added to the scoptions file, like MAP, BATCH, VERBOSE, additional
linker libraries, and so forth.  The additional options won't take
effect until you specify LINK on the SC command (if you are using
a makefile, you don't want to specify LINK in the SCOPTIONS file.)

|> 
|> $(PROJECT).o: $(PROJECT).c $(POJECT).gst

You need to put the GST first so it will be build before the .o file
in case both of them are out of date.

|> 
|> $(PROJECT).gst: $(PROJECT).h
|> 	sc MAKEGST $(PROJECT).gst $(PROJECT).h

You need to use a .c file that #includes the .h file, not the .h file
directly.  The way GSTs are set up to work, the MAKEGST option ignores
anything found in the file being compiled.  Normally, the file being
compiled is a .c source file, so you don't want #defines or struct
definitions specific to that .c file polluting your GST and being
used when compiling other files.

Also, you can specify the NOOBJNAME option when creating the GST and
the compiler won't run the optimizers or code generator.  Not only does
this save time and memory, it prevents the compiler from writing the
extra .o file that you really don't need.

|> Kari Sutela	sutela@utu.fi

Basically, the above method is what I always use to add GSTs to a
project.  Usually I use one of the .c files in my project as the
file to compile to generate the GST, but I do compile it as a
seperate target in the make script.

To summarize:

   *) Use the SCOPTIONS file for both compiler and linker options

   *) Use SC for linking (and assembling) instead of SLINK (or ASM).
      This allows you to issue simpler commands and also allows you
      to store your options in the SCOPTIONS file.

   *) Use a .c file to generate your GST.  It can either be a 
      specially-created .c file like V5.10 required, or it can 
      be one of the .c files in your project.

   *) Use the MAKEGST and NOOBJNAME options when creating the GST.
      It's OK to put the GST option in the SCOPTIONS file since it
      will be ignored when using MAKEGST.

Here's a typical setup for me.  Assume the following options in the
SCOPTIONS file:

Debug=SF
NoStackCheck
StructEquiv
Memsize=Huge
ErrorRexx
Map
MapHunk
MapXref
Batch
Lib lib:memwatch.lib

And the following SMAKEFILE:

OBJECTS=file1.o file2.o file3.o file4.o
HEADERS=project.h project2.h project3.h

project: project.exe

# "project.exe" is the debuggable version of the program.  The same
# link step will generate a map file due to the various MAP options
# in the SCOPTIONS file.

project.exe: project.gst $(OBJECTS)
   SC LINK $(OBJECTS) TO project.exe

# "project" is the stripped version of the program.  It will load
# faster if you aren't debugging it, but the map file is still
# valid for it in case you get enforcer hits.

project: project.exe
   SLINK project.exe TO project NODEBUG

# Generic compile command
.c.o:
   sc $<

# Build the GST.  We use a normal project .c file to compile, but
# the GST actually depends on the .h files in the project, not the
# .c file.   The NOOBJNAME option prevents the compiler from trying
# to generate code.

project.gst: $(HEADERS)
   SC MAKEGST project.gst project.c NOOBJNAME

# Rules for each .o file
file1.o: file1.c
file2.o: file2.c
file3.o: file3.c
file4.o: file4.c

# Special cleanup target.  Build this to clear out the whole thing.
# Note the backslash to escape the # in the commands below.  This
# is needed since # is a comment character by itself.
# If you build from workbench, make this into a seperate build
# script; this way you can click on BUILD, then shift-double-click
# on the script and clean up your project.
clean:
   gst unload project.gst
   delete \#?.o \#?.exe \#?.gst \#?.map project force quiet

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.