home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.programmer
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!stanford.edu!rock!concert!sas!mozart.unx.sas.com!walker
- 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
- Sender: news@unx.sas.com (Noter of Newsworthy Events)
- Message-ID: <BzEq65.9yH@unx.sas.com>
- Date: Thu, 17 Dec 1992 14:13:16 GMT
- Distribution: inet
- References: <BynD5B.35w@srgenprp.sr.hp.com> <Bz3zDo.1Jx@unx.sas.com> <S37732V.92Dec12145909@lk-hp-20.hut.fi> <Bz95w4.LI7@unx.sas.com> <JRAJA.92Dec15231111@vipunen.hut.fi> <1992Dec16.145012.6828@polaris.utu.fi>
- Nntp-Posting-Host: twix.unx.sas.com
- Organization: SAS Institute Inc.
- Lines: 155
-
-
- 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.
-
-