Setting up an individual developer for a project involves 1) setting up the 
developer sandbox, and 2) setting the developer's environment variables.

Choose an empty directory location and set up a developer sandbox tree:
 
% cd developer_location
% tar xvf $RPSL_HOME/usr/share/utl/rpslSandbox.tar

Put an ascii file in your home directory called .rpslauthor with your name and 
the class skeleton writer rpslNewClass will use this to stamp the author:
 
% cd ~
% echo "First M. Last" > ~/.rpslauthor

Set three environment variables that define the three-level sandbox heirarchy 
supported by RPSL. Recall that an RPSL sandbox contains source modules that
are checked out from the project and put under a local build directory, new
modules not yet put in the project repository, and a local usr target tree for
installing targets locally for testing (linking or executing). 

You could put the following statements in a startup rc file. For the c-shell 
the root location variable is as follows:
 
setenv RPSL_HOME <install_location>

At any one time, for a particular user, the project and developer variables 
each point to one place, but generally there would be more than one project 
and more than one user sandbox for each user. Therefore, for switching among 
these, point the environment variables for the project and user sandboxes to 
symbolic links and then set up the links to point to actual sandbox 
directories. 

For example:
 
% ln -s project_location ~/rpsl_proj
% ln -s developer_location ~/rpsl_user


Then in the startup rc file
 
setenv RPSL_PROJ <~/rpsl_proj>
setenv RPSL_USER <~/rpsl_user>


RPSL_HOME must be set because that's where the scripts and utility files are.
RPSL_PROJ is optional - RPSL will work without a project level. Finally,
RPSL_USER must be set simply because there needs to be a place to develop
and build.

Next, add the target locations to your LD_LIBRARY_PATH variable for shared object
files.  The order is critical here - local level first, global last, because
a local install of a library should be the one that's linked and tested during
development and modifications.
 
setenv LD_LIBRARY_PATH $RPSL_USER'/usr/local/lib:\
'$RPSL_PROJ'/usr/local/lib:'$RPSL_HOME'/usr/local/lib:...'

Then set the PKG_CONFIG_PATH so that pkg-config can find the pc files.  Order is
critical here too - the local install should be the one seen first when 
testing the latest version of a library under development.
 
setenv PKG_CONFIG_PATH $RPSL_USER'/usr/local/lib/pkgconfig:\
'$RPSL_PROJ'/usr/local/lib/pkgconfig:'$RPSL_HOME'/usr/local/lib/pkgconfig'

Finally, put the usr/bin and usr/local/bin directories in each of the three
sandboxes in the executable search path. For the example only $RPSL_HOME/usr/bin 
and $RPSL_USER/usr/local/bin are used.

if ( ! $?USER_PATH_SET ) then
    set path = ( \
    ...
    $RPSL_USER/usr/bin \
    $RPSL_USER/usr/local/bin \
    $RPSL_PROJ/usr/bin \
    $RPSL_PROJ/usr/local/bin \
    $RPSL_HOME/usr/bin \
    $RPSL_HOME/usr/local/bin \
    $path )
    setenv USER_PATH_SET 1       
endif


That's It!


--------------------------------------------------------------------------

For reference, here are the places ${RPSL_HOME} ${RPSL_PROJ} and ${RPSL_USER} 
are used:

 1. They are set in the shell rc script.
 2. They specify the link path for dynamic libraries in the shell rc script
 3. They specify the pkgconfig search path for pc files in the shell rc script
 4. They specify the executable search path in the shell rc script
 5. RPSL_HOME specifies the search path for m4 macro files in the bootstrap 
    script 
          aclocal -I config -I ${RPSL_HOME}/usr/share/aclocal
 6. RPSL copies certain skeleton files from RPSL_USER, RPSL_PROJ or RPSL_HOME 
    that are searched in that order - see the script rpslNewClass, for example.


top