Provided by: shapetools_1.4pl6-14_amd64 bug


       Shapefile.tmpl,  Makefile.tmpl, Release.tmpl, release.c.tmpl — templates in the shapeTools


       When working with the shapeTools Release Management System, all system model files (Shape-
       and  Makefiles)  must  be derived from templates, namely Shapefile.tmpl and Makefile.tmpl.
       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 macro.

       Release.tmpl  and  release.c.tmpl  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 Shape-/Makefile.

       Locations and General Macros

       BASE (inherited)
              The base directory of the project's central source repository.

              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) (eg. "/subsystem/library").

              A  short  name  for  the  developed system node. This name will also to be used for
              generating     release     identification     strings     having      the      form

       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 preprocessor.

       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
              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.

       INCLUDEPATH (inherited)
              Similar to LIBPATH. The location of project internal header files.

       The System Components

       TARGET 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

              A list of all programming language source files belonging to  the  system.  In  the
              case of C development, these are the .c files

              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 categories.

              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 Dependencies.

              All files, automatically produced during a build process except TARGET.  These  are
              usually the .o files.

       Tools, Flags and Libraries

       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 compilation flags).

       LDFLAGS (inherited)
              The linker flags.

       RANLIB (inherited)
              The program for adding a table of contents to archives.

       SYSLIBS (inherited)
              Additional system libraries to be linked to TARGET

              Local libraries to be linked to TARGET

              Libraries to be invoked when executing "lint".

       Shape Specific Macros

              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 Shapefiles.

       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 shippable package.

              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

       SHAPELIBPATH (inherited)
              The directory, where all common parts of the shape_RMS environment reside. Here are
              all the templates and shape include files located.

              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 machine architectures.


       Shapefile.tmpl- Template for node specific Shapefiles
       Makefile.tmpl- Template for node specific Makefiles