120 likes | 202 Views
CMT review. Outline installing a new version new features in CMT v1r5 problems and requirements. Installing a new CMT version. Download the source under $SOFTWARE/CMT/CMTv1r5.tar.Z Then cd $SOFTWARE/CMT/ gunzip CMTv1r5.tar.Z tar xvf CMTv1r5.tar cd CMT/v1r5/mgr
E N D
CMT review • Outline • installing a new version • new features in CMT v1r5 • problems and requirements F.Ranjard / EP-ALE
Installing a new CMT version • Download the source under • $SOFTWARE/CMT/CMTv1r5.tar.Z • Then • cd $SOFTWARE/CMT/ • gunzip CMTv1r5.tar.Z • tar xvf CMTv1r5.tar • cd CMT/v1r5/mgr • cp $CMTROOT/mgr/.cmtrc . • INSTALL • source setup.csh • gmake • check carefully the path with • cmt show path F.Ranjard / EP-ALE
CMT v1r5 new features • Version_strategy • if your application use 2 different versions of the same package, CMT will try to choose one • if you use packA v1 and v2 CMT will stop • if you use packA v1 and v1r1 CMT will choose packA v1r1 • you can change the default behaviour of CMT using the new feature version_strategy • if you want to use packA v2 in your application even if some other used packages are using and older version of packA • version_strategy first_choice • use packA v2 • use packB v1 • CMT will keep packA v2 even packB uses packA v1 F.Ranjard / EP-ALE
CMT v1r5 new features (2) • Get the most recent version of a package • use CERNLIB • use CLHEP • include_path “none” • by default the include search path is $<PACKAGE>ROOT/src • we use include_dirs to specify the package include directory • we don’t need a default include path • that is obtain with the new include_path “none” feature • this is put in LHCbCMT package, all other packages inherit from it. F.Ranjard / EP-ALE
CMT v1r5 new features (3) • By default CMT rebuilds all *.make files it needs everytime you run gmake. • when you change only $CMTPATH, it happens that CMT does not recognize the change : • rm *.make • gmake • By default CMT is very verbose: • during compilation you get the full compilation statement for every files. • To get a QUIET compilation mentionning only the file name, the warnings or/and errors • gmake QUIET=1 or • setenv QUIET 1 • gmake F.Ranjard / EP-ALE
CMT v1r5 new features (4) • new way to build libraries • CMT v1r4 • CMT compiled one file at a time, added to the library, removed the object file • CMT v1r5 • CMT compiles all files, creates the library, keeps the object files • you need 2 x the space !!!!! Not a so good feature F.Ranjard / EP-ALE
LHCb use of CMT • EXTLIB • sets specific computing centre environment variables depending on the value of $CMTSITE • $CMTSITE must be set at login time and EXTLIB/mgr/requirements must be customized accordingly. • LHCbCMT • is the LHCb customization of CMT. It contains • it uses EXTLIB • it sets compilation flags for all platforms ( debug and no-debug) • it sets link flags for all platforms (static and shareable) • it sets various LHCb tags • dbase • is a package used by any Gaudi or SICB application F.Ranjard / EP-ALE
LHCb use of CMT (2) • LD_LIBRARY_PATH • to link shareable libraries we need to build the LD_LIBRARY_PATH environment variable • each package add its own path to the existing path • path_append $GAUDIROOT/$DEBUGDIR • the real path is set when you source setup.csh of your package (library or application) • to change the LD_LIBRARY_PATH to debug mode • unsetenv LD_LIBRARY_PATH • source setup.csh -tag=Linuxdbx • To help use of LD_LIBRARY_PATH application package should contain a job/ subdirectory F.Ranjard / EP-ALE
LHCb use of CMT (3) • GaudiConf • is a package which contains the StandardOptions.txt file • the $STDOPTIONS variable to retrieve this file in your application is set in the requirements file. • GaudiJob • is an example of a user application package: • doc, job, main, mgr, src • the requirements file uses • GaudiConf to get the StandardOptions • dbase to get access to *.cdf and *.ddf files • Gaudi packages to get the framework • user packages • and build the user application F.Ranjard / EP-ALE
LHCb use of CMT (4) • The job/ directory contains script to run the application and the user jobOptions file • cd job/; lsGaudi.job <executable>Options.txt • Gaudi.job takes care of • set MODE = “Linux” or “Linuxdbx” • unsetenv LD_LIBRARY_PATH • source setup.csh -tag=$MODE • run interactively or in batch • the user needs to provide the path to his application package and the name of his executable. • To run a job interactively • Gaudi.job or Gaudi.job Linuxdbx • To run it in batch • bsub < Gaudi.job F.Ranjard / EP-ALE
Possible improvements • Return to the old way to build libraries. • Build super-libraries • we would like to consider the Gaudi framework as one library • we link with CERNLIB and not with ZEBRA, HBOOK, ect… • we don’t mind what is the version # of the packages which are used by the Gaudi framework • that would reduce the length of $LD_LIBRARY_PATH • Any suggestions? F.Ranjard / EP-ALE
Some recommendations • Try to use the most recent versions of various applications. • It is difficult to make sure that old versions still work in new environment. • At CERN we have no more access to redHat5.1 F.Ranjard / EP-ALE