Shapefile.tmpl, Makefile.tmpl, Release.tmpl, release.c.tmpl — templates
in the shapeTools RMS
When working with the shapeTools Release Management System, all system model
files (Shape- and Makefiles) must be derived from templates, namely
. The templates define a certain
number of standard macros names used througout the shapeTools RMS. Deriving
system model files from the templates is mainly filling in the appropriate
macro values. The following section gives an overview of all macro names
defined in the templates and a short explanation on the semantics of each
are templates for release
identification files. They do not need to be adapted in any way.
The following is a list of macros that occur in the Shape- and Makefile
templates. Most of them are defined in the Makefile. As Makefiles are included
in the Shapefiles, these are used by both, calls of make and calls of shape.
Some shape specific macros (defined in the Shapefile template) are described
at the end of this section.
As the shapeTools RMS performs recursive calls of shape (resp. make), some of
the standard macro settings get inherited to a recursively called
sub-build-process. The macros are marked in the list accordingly. The
inheritance mechanism allows installation dependent macros (eg. BASE) to be
set for the whole project by only modifying the value in the top level
Locations and General Macros
- BASE (inherited)
- The base directory of the project's central source
- The relative path name of a system node within the
project's source repository. In the top node, this macro has an empty
value. For subsystems, it is to be set to the path relative to $(BASE)
- A short name for the developed system node. This name will
also to be used for generating release identification strings having the
- HOSTSYSTEM (inherited)
- The underlying operating system. The value of the
HOSTSYSTEM macro is built after the schema s-<opSys>. This macro has
different meanings in make and in shape.
Make treats it as an an extension to a known base path for accessing
the appropriate versions of operating system dependent files. The base
path points to a directory containing subdirectories for each supported
operating system type. All subdirectories carry the same list of filenames
with in each case different (operating system specific) contents.
For shape, the HOSTSYSTEM macro is treated as variant definition.
With the corresponding variant definition defined in the variant
definitions include file (see shape_stdvar(7)), a whole bunch of macros is
set (resp. modified).
- HOSTTYPE (inherited)
- The machine architecture. This macro should be used for
installing different binaries (for different machine architectures)
compiled from the same program source in a heterogeneous network. On
systems containing the arch command, HOSTTYPE may be dynamically
set by HOSTTYPE=`arch`. This macro is currently not supported in the
default installation setup.
- SWITCHES (inherited)
- Preprocessor switches for conditional compilation. This
macro may be used for system wide switching on/off certain program
behavior. The SWITCHES are passed as arguments to the language
- INSTALLBASE (inherited)
- Locations and modes for installation of executables, header
files, libraries, and manuals. The INSTALLBASE macro eases the definition
and redefinition of the following installation path macros, as the values
of these may cite INSTALLBASE. Each of the installation path macros may
also be set to a value independent of INSTALLBASE.
INSTALLBINPATH (inherited) - installation directory for executables
INSTALLBINMODE (inherited) - file protection mode to be set for installed executables
INSTALLINCPATH (inherited) - installation directory for include files
INSTALLINCMODE (inherited) - file protection mode to be set for installed include files
INSTALLLIBPATH (inherited) - installation directory for libraries
INSTALLLIBMODE (inherited) - file protection mode to be set for installed libraries
INSTALLMANPATH (inherited) - installation directory for manuals
INSTALLMANMODE (inherited) - file protection mode to be set for installed manuals
Installimn manuals using the INSTALLMANPATH macro expects appropriate manX
(man1, ...) subdirectories there.
- LIBPATH (inherited)
- The directory, where local libraries, developed within the
project, shall be installed for project wide use.
The System Components
- INCLUDEPATH (inherited)
- Similar to LIBPATH. The location of project internal header
- The name of the main target to be built. This can be a
program, a library, or anything else to be produced. If the construction
of the main target does not require any real transformation (if eg. only
subsystems are to be built), it is advisable to have a file
$(SUBSYSTEMNAME).date as main target. The system building action should
just touch this file, so that it's modification date shows, when the last
system building action happened. If the managed system consists of
multiple programs, this macro should be multiplied (eg. TARGET_1 TARGET_2
... TARGET_N). In that case, all places in the Makefile, where $(TARGET)
occurs have to be modified accordingly !
- The name of a file, used as release number generator. With
each new release, a new version of this file is generated automatically.
When developing a program, this file ideally contains exactly one function
returning a version identification string. When using the ShapeTools
version control system's attribute citation mechanism, the contents of
such a file needs only to be written once and never be changed afterwards.
There are different prototypes for such a file in $(LIBPATH)/shape. For
system parts not incorporating an executable program, any other source
file could be chosen as release number generator. In any case should
$(VERSIONFILE) never be saved explicitly by the user.
- The object file (.o file) derived from VERSIONFILE. This
macros is only to be set, when VERSIONFILE contains program text.
- All subdirectories, where additional parts of the system
wait for being built. For each subtarget, a recursive shape (resp. make)
call is performed with the current macro settings getting inherited. The
SUBSYSTEMS will be build before TARGET. This macro may also be empty.
- This is a list of aliases for TARGET. This macro is to be
set, when TARGET should be accessible by multiple names (eg. a program to
be activated under different names).
- A list of all programming language source files belonging
to the system. In the case of C development, these are the .c
- The header files belonging to the system. The .h
files in case on C development.
- Auxiliary source files. These are source files that shall
also be processed when building the system, but that are not genuine part
of the system. These are for example sources of auxiliary test programs,
needed to perform test in the development area.
- Auxiliary header files, similar to auxiliary sources.
- Equally named source and header files, located in
subdirectories, each named after a certain variant. For system building,
only one of the directories is used, according to the specified
HOSTSYSTEM. In the shape_RMS environment, the subdirectory names should be
chosen from the value set of the HOSTSYSTEM macro (for more details, see
the description of the HOSTSYSTEM macro above).
- The manual files for the system, distinguished by
- All source components belonging to the system. These are
the source files (SOURCES), the include files (HEADERS), the manuals
(MANUALS), the Shapefile, the Makefile and a (generated) file named
Tools, Flags and Libraries
- All files, automatically produced during a build process
except TARGET. These are usually the .o files.
- MAKE (inherited)
- The make program. This macro is used for recursive calls of
make. During execution of shape, this macro is explicitly (in the
Shapefile) set to the value of the SHAPE macro. This causes recursive
builds also to be performed by shape.
- SHELL (inherited)
- The shell to be used by make, resp. shape for interpreting
the build actions in the Makefile or Shapefile.
- CC (inherited)
- The C compiler to be used.
- CFLAGS (inherited)
- The C compilation flags (see SWITCHES for additional
- LDFLAGS (inherited)
- The linker flags.
- RANLIB (inherited)
- The program for adding a table of contents to
- SYSLIBS (inherited)
- Additional system libraries to be linked to TARGET
- Local libraries to be linked to TARGET
Shape Specific Macros
- Libraries to be invoked when executing
- The default version binding (version selection) rule to be
applied for each component. Selection rules are globally defined in the
$(SHAPELIBPATH)/stdrules file (see shape_stdrul(7)). It is strongly
recommended, to define a project wide version selection policy only in the
stdrules file and to renounce version selection rules in local
- BINDDEFAULT (inherited)
- Internal name for VERSIONS. Should not be redefined.
- BINDINSTALL (inherited)
- THe default version binding rule to be applied when
installang a system or system part for project wide or global use.
- COMPILER (inherited)
- The compile environment. This macro represents a shape
variant selection. With each variant, a whole bunch of macro
settings may be associated, so that the COMPILER variant not only sets the
actual compiler (CC), but also some compilation flags. See stdvar for the
default variant raster. The same as version selection rules, the variant
raster should be defined project wide. Local variant definitions can very
easyly lead to confusion and improper configurations.
- QUALITY (inherited)
- The desired quality of the produced object code. This is
also a variant definition (see stdvar for other options).
- RELEASEBASE (inherited)
- PARTIALRELEASEBASE (inherited)
- The base of the directory tree, where prereleases and
releases of the system are to be constructed. When building a
(pre)release, the appropriate versions of all components of the system are
copied from the development area to the release area. The release area
should only be used for performing final tests and for bundling up a
- The relative path within the release or partial release
area where the suorce files ar to be copied to. Ususally, this is
identical to $(NODEPATH).
- The relative path within the release or partial release
area where all manuals are gathered.
- SHAPELIBPATH (inherited)
- The directory, where all common parts of the shape_RMS
environment reside. Here are all the templates and shape include files
- This is rather a pseudu-target, than a Macro. Shape
interprets this as directive that causes only the listed files
($(OBJECTS)) to be put into the derived object cache. Defining the pseudo
target .NOBPOOL: (without dependents) deactivates the derived object
cache. This is necessary, when the development environment requires access
to the same derived object cache from machines with different
architectures. The reason is, that "dbm" databases (and derived
object caches use dbm databases) are not portable between different
Shapefile.tmpl - Template for node specific Shapefiles
Makefile.tmpl - Template for node specific Makefiles