Table of Contents
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
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:
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.
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.
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.
Table of Contents
Last modified: Thu Dec 1 01:24:51 EST 2005