Table of Contents

RPSL build scripts
The RPSL utility scripts are in $RPSL_HOME/usr/bin.   

The fundamental RPSL scripts are:

rpslNewLibTree name namespace  

  This starts a library directory tree with the given name and sets the default
  namespace for any new class files that are started with rpslNewClass (see below).  
  This command can start a new library tree anywhere - either under the RPSL 
  tree or elsewhere.  A good choice is under the RPSL tree build/ directory. Once
  started, the library top level directory can be renamed to be anything, but the
  library name, or library name appended with version or release are good choices.

rpslNewExecTree name           

  This starts an executable tree with the given name.  As with a library, this
  module can go anywhere but a good choice is under build/.  After it is created
  the top-level directory can be renamed to anything you like. 


  This is the main RPSL command.  It scans for source files and syncs the build 
  after files are added or the RPSL parameter file is modified.  It doesn't need 
  to be run again if source files are modified. It is only required after adding
  or deleting source files, or after changing the rpslParams file.  The script 
  calls "make uninstall" and "make clean" first, then updates the RPSL-generated 
  files and runs a bootstrap script (aclocal, autoheader, libtoolize, automake, 
  autoconf). This results in configure and the's. Note that the command
  must be run at the top-level of a module directory tree (where configure will 
  eventually go).

  Inside an autotools tree only source under the primary library or executable 
  directory will be scanned. The primary library directory is always called the 
  root name of the library.  The primary executable directory is named the executable 
  name.  RPSL supports a primary executable directory called "src" but this is 
  depreacated.  You can add any number of other directories to the tree and they will 
  be ignored by RPSL.


  This is a helper script in the top-level module directory that calls configure 
  with default arguments to generate the necessary makefiles. This script also
  takes command line arguments which, when present, disable the built-in defaults 
  and get passed directly to the call to configure.

RPSL also provides a script to generate new class source files:

rpslNewClass  classname [templatename] (makes a class skeleton with the given name)

  If the templatename argument is given, the skeleton will be that for a simple 
  templated class and templatename will be used for the generic type.

RPSL secondary scripts used less often or called by the main ones are:

rpslBootstrap            (runs the Gnu autotools to make, etc.)
rpslUpdateTree           (updates the library or exec tree)
rpslUpdateLibTree        (updates the RPSL-generated files in a lib tree)
rpslUpdateExecTree       (updates the RPSL-generated files in a exec tree)
rpslGenEtags             (generates an etags TAGS file)
rpslCleanTree            (cleans a module autotools tree of generated files)

Currently RPSL recognizes the following source extensions:

*.cpp Implementation file for non-templated c++ code
*.cxx Implementation file for non-templated c++ code
*.cc  Implementation file for non-templated c++ code
*.c   Implementation file for non-templated c code

*.tpl Implementation file for templated c++ code
   This file extension is optional, but good practice and it
   is installed in the include directory along with the corresponding 
   templated header interface file.  The header file includes the tpl
   file, not the user.

*.h   Interface header file for templated or non-templated c++ or c code
*.hpp Interface file for non-templated c++ code
*.hxx Interface file for non-templated c++ code
*.hh  Interface file for non-templated c++ code

To add or subtract source extensions please edit the scanForSourceFiles 
function in the rpslCommonFunctions script file in the directory 
$RPSL_HOME/usr/bin. The cpp and h extensions must remain, however, because 
those are the extensions RPSL uses for the library utility filenames it
creates that must be scanned and included in the build.


Table of Contents
William Snyder
Last modified: Sun Aug 28 22:15:38 EDT 2005