The figure above shows the three sandbox levels associated with group development 
in RPSL. RPSL was inspired by the Sun Workshop system of configuration management
and developer coordination.  RPSL can employ any CM tool, such as CVS or 
Subversion. The default repository directory name is cvs.

Each level is a directory tree that houses source and targets.  For 
details on the tree structures see RPSL directories and targets. 

Recall that the main theme for RPSL is that the library is the unit of reuse and 
except for its dependencies on other libraries, is an independent autotools tree. 
A user executable or library module can include and link to installed libraries
in the same sandbox or in the project or global sandboxes. 

For a sensible group build system the libraries in the project sandbox must 
never link to ones in any user sandbox.  When building and installing, the 
"buildmaster" for the project should point their user path to an empty directory.
Likewise, the buildmaster for the global home sandbox should disable both their
project and user paths because a home library should only link to other home
libraries. 

The rpsl scripts and the pkg-config with autotools take care of the include and 
link paths automatically. The rpslParams file in each autotools tree (each module) 
specifies what libraries should be included and linked. The PKG_CONFIG_PATH is searched
for a library matching the name and the first one found will be tested against the
required version.  If the test fails, the search ends and configure stops with an
error.  If there is another library later in the search path that does meet the version
requirements it will not be found.

There is a single rpsl home tree at the global level that contains the RPSL 
scripts and any libraries stable and universal enough to be shared across 
projects. This is a good place for external libraries such as FFTW.

There are one or more project trees.  Each one contains modules associated 
with a group development project (one or more libraries and one or more 
executables).  The project directory structure is the same as the RPSL home 
library structure except it generally would hold both library modules and 
executable modules (generally no executables are kept in the rpsl home tree).

Each developer in a group has one or more local user development sandboxes that 
contain source modules for libraries and executable modules. A user should have 
a different sandbox for each particular project.  Only one of these sandboxes 
is active via the symbolic link at $RPSL_USER.

As an example, a development process could proceed as follows:

STEP 1.
-------
A new project group tree is started that is readable and writeable to developers.
It can contain project-specific class skeletons where, for example, the project
name and a specific project copyright would be standardized. See RPSL utility files.

STEP 2.
-------
A developer is assigned to develop a library or executable module and starts 
this in their local user sandbox.  This module under development can depend on 
libraries installed in the user, project and rpsl home trees and these are 
searched in that order to satisfy the dependencies specified in rpslParams. 
For more information see RPSL parameter file. 

STEP 3.
-------
After the initial implementation of a new module stabilizes the module is checked 
into the project sandbox repository and checked out there into the build directory
by the software lead for building and installing for shared use.  This makes 
it available to other modules in the project tree as well as to other 
individual developer sandboxes for writing dependent modules.

If the existing, checked-in module needs to be updated, a developer can 
check it out to their local user sandbox, modify and test it locally, and then
check it back into the project sandbox for building and installing.

Occasionally a library may be deemed universal and stable enough to be shared across 
projects, or it simply is used by more  than one project.  In that case it can be 
checked into the home tree ($RPSL_HOME) and built there to make it visible to multiple 
projects.  This is also a good place for some external libraries, such as fftw.

That's basically it.  Note that RPSL fully exploits the library versioning features 
of unix and the autotools.  The Library naming and versioning page explains the 
release and shared versioning system.

top