Several levels of evaluation about using the CMT tool have already been performed onto different phases of the offline software (July 2000 on offline-01-02-01 and March 2001 on offline-01-03-00).Now we are starting another step towards a more complete and more synchronized integration of the offline software in the CMT environment.
The goal now is to provide a really usable release, with in particular a true synchronization with the HEAD of the CVS repository (or at least with the most recent tags).
Another goal is to introduce the most recently agreed conventions on software organization, or on software management. From what will be provided, users should be able to start developing against released packages.
Due to the true synchronization constraint stated above, the integration will be conducted iteratively, starting from basic packages or more stable ones ending with more recent and more complex ones. Contributions from package authors are kindly expected.
We expect having completed this work mid-june 2001
A disk area used to receive the offline packages organized and built using CMT has been allocated:/afs/cern.ch/atlas/software/dist/ART_Evaluations/ReleasesWithCMTFrom that location, named ${cmtdist} in this document, all offline packages will be installed, following the current package hierarchy, as CMT packages.
CMT Version tags for all packages will be built according to the most recent tag available for the package at the time the package is installed there. This will evolve with time as new tags are produced. New versions of each individual packages will be installed there accordingly
The current directory organization is preserved as it is, with one additional meaning for the main structure entries such as
they are now used as container packages, and as such they are true CMT packages and they provide a list of use statements for all packages available below the corresponding structure. They may act as management structures for each corresponding software domain.
- External
- Utilities
- ...
Configuring CMT - first approach
If anyone wants to make use of the packages available in this area, here are the required settings (that could be installed eg. within one's login script):> . /afs/cern.ch/sw/contrib/CMT/v1r9/setup.sh > export CMTSITE=CERN > export LHCBCERNINC=/cern/pro/include > export SITEROOT=/afs/cern.ch > export CMTPATH=/afs/cern.ch/atlas/software/dist/ART_Evaluations/ReleasesWithCMT > export CMTPATH=${CMTPATH}:/afs/cern.ch/atlas/offline/external/Gaudi/0.7.0Configuring CMT - second approach
Another (prefered) way of getting the same result would be to take complete benefit of CMT as follows:
- create in your home directory the following requirements file (~/requirements)
set CMTSITE CERN (1) path_remove CMTPATH /afs/cern.ch/atlas/ (2) path_append CMTPATH /afs/cern.ch/atlas/software/dist/ART_Evaluations/ReleasesWithCMT path_append CMTPATH /afs/cern.ch/atlas/offline/external/Gaudi/0.7.0 set LHCBCERNINC /cern/pro/include (3) set SITEROOT /afs/cern.ch (3)
- May be different if you are on a different site
- to cleanup previous settings
- settings required by the Gaudi environment
- Only once, configure your environment
> . /afs/cern.ch/sw/contrib/CMT/v1r9/mgr/setup.sh > cmt config- Then calling . setup.sh (either interactively or from your login script) will restore at any time the original settings for CMT itself, CMTSITE, CMTPATH, etc.
- One may notice that the requirements file we are considering here (which could be called the login requirements file) might also contain any other set, pathxxx, alias cmt statements, and as such work as a platform independent login script, and then act as a replacement for your login script.
Creating a new package
Here we consider how to create a new package, meant to contain your code and to use the other packages available in the CMT release area.> cd mydevarea (1) > cmt create Foo Foo-00-00-01 (2) > cd Foo/Foo-00-00-01/cmt > vi requirements (3) use CLHEP CLHEP-00-00-08 External ... > ... > preparing for the CVS import > cmt config (4) > cd ../ (5) > cvs import -m "First import" -I i386_linux22 offline/Foo Atlas Foo-00-00-01 > setting a new tag > cvs tag Foo-00-00-02 (6)
- This is your prefered development area
- This creates your package, and defines its starting tag
- First operation consists in adding specifications in the requirements file
- Preparing the original cvs import generally consist in cleaning up all undesired files for CVS
- The import operation will typically import everything of your package, besides the binary files, and files re-generated by CMT
- Later on, after some changes, retagging will occur from the top-level directory
Working on an existing package
Here, the package we want to change already exists in the CVS repository.> cd mydevarea/ > cmt co -o offline Control/AthenaExamples/AthExHelloWorld (1) > cd Control/AthenaExamples/AthExHelloWorld/AthExHelloWorld-00-00-03/cmt/ > . setup.sh (2) > gmake (3) > cd ../share/ > athena (4)
- The cmt checkout operation will understand what is the most recent tag and will create the version directory accordingly (the most recent tag is used but the package is checked out from the HEAD of the repository)
- This will configure all environment variables required for this package at this version
- One can now rebuild the package constituents
- The example shows the specific use of the main program obtained from AthenaCommon. In our case the word athena is defined as an alias to the AthenaCommon main
This package only contains global definitions related with general Atlas software management policies, such as where header files are conventionally located (eg. in ../<package>). Global patterns are automatically and transparently applied by all packages that are client of AtlasPolicy (typically all Atlas packages), whereas non-global patterns must be manually applied by individual packages, using the apply_pattern <pattern-name> statement.
global pattern name definition, usage default_include_path defines the default include search path for all packages kits defines the document generators used to generate the tar-balls (this is an experimental feature)
pattern name definition, usage default_rpath Defines a shared library access path in the binary directory of the package default_linkopts To be applied when one shared library named after the package name is provided
extras=<additional linker options>default_no_share_linkopts To be applied when one static library named after the package name is provided
extras=<additional linker options>installed_linkopts to be applied when one library is provided by the package, and when this library is expected to be installed as a symbolic link in client packages
the macro <package>_libraries will have to be specifieddefault_library very basic pattern for the simplest case, where one shared library only composed of C++ source files in ../src is provided by the package default_installed_library same pattern as default_library except that the minimal library will be installed in client packages no_include_path To be applied when a package does not provide any header file (typical for interface packages)
This package contains a reference to the exhaustive list of all validated package in each release. In particular, in the context of this evaluation phase, the list will be continuously growing until the complete offline software base is rebuilt.
The releases currently available are:
- AtlasRelease version AtlasRelease-01-03-02
- AtlasRelease version AtlasRelease-01-03-05
package name version tag Utilities Utilities-01-02-02 External External-00-02-00 Tools Tools-01-02-01 graphics graphics-01-00-10 Control Control-00-07-04 Database Database-00-00-08 DetectorDescription DetectorDescription-00-00-25 Event Event-00-00-38 atrig atrig-04-24-02 LArCalorimeter LArCalorimeter-00-00-22 TileCalorimeter TileCalorimeter-00-00-08 InnerDetector InnerDetector-00-00-35 MuonSpectrometer MuonSpectrometer-01-01-10 Calorimeter Calorimeter-00-00-06 Generators Generators-00-00-21 Simulation Simulation-00-01-02 Reconstruction Reconstruction-01-03-05 Applications Applications-01-01-01
Top packages installed so far
commons 01-03-04 geant3 21-08-33 slug 01-23-35 atlsim 01-41-02 gencl 00-00-05 gcalor 00-00-31 genslug 00-00-31 genz 00-00-33 ggenz 00-00-31 herwig 00-00-07 jetfinder 00-00-06 jetset 00-00-06 matele 00-00-05 njets 00-00-05 pythia 00-00-07 vecbos 00-00-08 atlfast 00-02-09 atgen 00-00-07 atdummy 00-00-36