variable | value |
---|---|
ALICE | directory |
ALICE_LEVEL | pro |
ALICE_ROOT | $ALICE/$ALICE_LEVEL |
ALICE_TARGET | `uname` (i.e. result of the Unix uname command) |
LD_LIBRARY_PATH | $ALICE_ROOT/lib/tgt_${ALICE_TARGET}\:$LD_LIBRARY_PATH |
SHLIB_PATH | $ALICE_ROOT/lib/tgt_${ALICE_TARGET}\:$SHLIB_PATH |
PATH | $PATH\:$ALICE_ROOT/bin/tgt_${ALICE_TARGET} |
At this point you should logout, login again and check that the symbols are set correctly.
File | Content |
---|---|
Either | |
AliOfflineMM.mm-pp.tar.gz | Code and the data files of ALICE Off-line |
Or | |
AliLibsMM.mm-pp.tar.gz | Code and the data files of the auxiliary libraries |
AliRootMM.mm-pp.tar.gz | All the code and the data files of the AliRoot system |
MM.mm-pp is the number of the latest Major and minor version and the patch number. The file(s) have to be unpacked into the $ALICE directory via the command:
$ gtar xvfz Ali[...].tar.gz
$ cd $ALICE $ cvsa co -d pro AliRoot
$ cd $ALICE_ROOT $ gmake cernlibs
$ cd $ALICE_ROOT $ gmake
$ cd $ aliroot
If the ALICE environment is set up correctly, the $ALICE_ROOT/lib/tgt_$ALICE_TARGET directory is in the shared libraries load path, and the $ALICE_ROOT/bin/tgt_$ALICE_TARGET directory is in the PATH variable. This means that the command aliroot will in fact correspond to the file $ALICE_ROOT/bin/tgt_$ALICE_TARGET/aliroot.
This is convenient for the normal user, but as soon as the user wants to modify one or more directories, this arrangement becomes inefficient because if a local copy of one of the shared libraries is remade, the linker will always find the official unmodified one that sits in the above directory before the local one in the load library path. Moreover, and unless the full path is specified, the local version of the aliroot executable will be ignored and the official version executed.
Therefore in order to develop one or more packages locally (let's say the TPC) and make modifications, the following steps should be performed. We suppose here that the remote cvs server has been setup correctly as explained in the code development section.
$ mkdir AliRoot | create the working directory |
---|---|
$ cd AliRoot | set default to it |
$ mkdir pro | create pro subdirectory |
$ cd pro | set default to it |
$ ln -s $ALICE_ROOT/* ./ | link all files here |
$ rm lib | remove link for library, we need a local file here to containing the new TPC library |
$ rm bin | remove link for bin directory, we need it to rebuild aliroot executable |
$ rm TPC | remove link for TPC subdirectory, we need the real files here |
$ rm ALIROOT | remove link to ALIROOT subdirectory, may be this is not really necessary on all systems, but we do it just to be on the safe side |
$ cvsa co TPC | get from the cvs server the TPC files to be modified |
$ cvsa co ALIROOT | get from the server the ALIROOT files to recreate the executable |
$ mkdir -p lib/tgt_$ALICE_TARGET | create library directory |
$ cd lib/tgt_$ALICE_TARGET | set default to the lib directory |
$ ln -s $ALICE_ROOT/lib/* ./ | link all libraries here |
$ rm libTPC.sl | remove link to TPC library, we need a real one |
$ changeRoot $HOME/AliRoot | change the AliRoot root to $HOME/AliRoot |
$ rehash | make sure that the new PATH is taken into account by the shell |
$ cd $ALICE_ROOT/TPC | (1) set default to TPC directory |
$ make macroclean | clean up all objects |
$ emacs AliTPCv1.cxx | (2) edit all the files... |
$ make | (3) recreate ../lib/libTPC.sl |
$ cd ../ALIROOT | set default to ALIROOT directory |
$ make macroclean | clean up object files |
$ make | make new executable |
$ cd directory | (4) set default elsewhere |
$ aliroot | (5) run aliroot |
Steps 1-5 are the normal development cycle after the first pass through the procedure.