1. The introduction of CMT Version v1r14

2. General index 1.presentation 2.how to install CMT 3.how to write a requirements file 4.how to use CMT

3. Presentation 1.the function of the CMT This environment, based on some management conventions and comprising several shell-based utilities, is an attempt to formalize software production and especially configuration management around a package -oriented principle. The environment provides conventions (for naming packages, files, directories and for addressing them) and tools for automating as much as possible the implementation of these conventions. It permits the description of the configuration requirements and automatically deduce from the description the effective set of configuration parameters needed to operate the packages (typically for building them or using them). 2.the facility of the CMT

4. How to Install CMT Supported platforms CMT has been ported and tested on a wide range of machines/operating systems, including : Dec-Unix V4.0 HP-UX-10 (several types of platforms) Aix-4 Solaris IRIX Several variants of LynxOS Linux 2.X Windows 95/98/NT/windows2000 in various environments: 1.CYGWIN_NT-5.1 environment 2.nmake based environment 3. MSDev/VisualC 6 environment 4. MSDev/VisualC 7 environment Darwin(Mac OS X)

5. On Redhat Linux Platforms For those platforms, a binary RPM is available. The installation procedure becomes: 1.> wget http://www.cmtsite.org/v1r14pxxx/CMT-v1r14pxxx- 1.i386.rpmhttp://www.cmtsite.org/v1r14pxxx/CMT-v1r14pxxx- 1.i386.rpm 2.> Rpm -Uvh --relocate /CMT= /CMT CMT-v1r14pxxx- 1.I386.Rpm 3.> Source /CMT/v1r14pxxx/mgr/setup.[C]sh Once the installation is complete, CMT is ready to use.

6. Install a Package A package is primarily defined by a name and a version identifier (this duet actually forms the complete package identifier ). These two attributes will be given as arguments to cmt create such as in the following example : csh> cd mydev csh> cmt create Foo v1 Packages are still the heart of the software decomposition. What makes a package a CMT package? Prefix / package / version-tag / cmt / requirements Where version-tag takes the form letters n [letters m [ letters p ] ] v1 v1r2p3 AGDD-00-00-37 offline-01-03-01

7. Lastly, this newly created package may be removed by the quite similar remove command, using exactly the same arguments as those used for creating the package. csh> cd mydev csh> cmt remove Foo v1 Logical vs physical structure Packages can be hierarchized somewhere/A/v1/cmt somewhere/A/B/v1/cmt somewhere/A/B/C/v1/cmt A, B and C are CMT packages There is no implied logical relationship between A, B and C Logical relationships are only specified through the use constraints

8. The directory structure of a package area/package-name/version-tag/cmt /requirements /src /sources /package-name /headers /i386-linux22 /linux binaries /sun4u /sun binaries /insure /insured binaries /classes /java binaries Public release Private dev. Common software Inter-project com. Domain specific dev. Search list defined in CMTPATH v1 v2r1 v3r1p1 Specified at package creation Obtained by cmt checkout Automatically created at build time and on demand according to cmt system or when providing a user defined tag ( gmake tag=insure ) Available through the macro $( _tag)

9. write a requirements file Everything goes into the requirements file in terms of CMT statements PACKAGE Author author, manager Use use Linkset macro _linkopts GNUmakefile.in Library, application library, application Make macros macro Test procedures configure.in #define xxx macro cpp_flags “ -Dxxx ” env.sh.in Export x=value set x “ value ” path_append LD_LIBRARY_PATH Conventions, behaviors Include path include_path, include_dirs Shared libraries, make_fragment, pattern document generation

10. An example(A) The requirements file package MagneticField author Laurent Chevalier author Marc Virchaux use AtlasPolicy v2r1 use CxxFeatures v2r1 Utilities use CLHEP v2r1 External include_dirs $(MAGNETICFIELDROOT)/MagneticField branches MagneticField doc src test... Provides definitions for standard Atlas conventions (include paths, directory structure, default behavioural patterns, …) An additional (non standard) include search path Describes additional subdirectories (branches) specific to this package

11. An example(B)... apply_pattern default_no_share_linkopts library MagneticField -no_share \ AbstractMagneticField.cxx \ MagField.cxx \ MagFieldFor.cxx \ MagFieldGradient.cxx \ Tableau.cxx \ reamag.F \ thanatos.F... Apply a “pattern” (defined in ATlasPolicy): Provide client packages with information needed to link with static library provided this package. The requirements file

12. An example(C)... apply_pattern default_no_share_linkopts library MagneticField -no_share \ AbstractMagneticField.cxx \ MagField.cxx \ MagFieldFor.cxx \ MagFieldGradient.cxx \ Tableau.cxx \ reamag.F \ thanatos.F... This describes a (static) library and all its source files. By default they are searched in../src The result will be libMagneticField.a The requirements file

13. An example(D)... application test -check../test/main.cxx private macro data_file "/afs/cern.ch/atlas/offline/data/bmagatlas02.data” macro test_pre_check "ln -s $(data_file) test.dat" macro test_check_args "test.dat" macro test_post_check "/bin/rm -f test.dat" macro test_dependencies MagneticField Create an application named test, with one source file run with the command > gmake check The requirements file

14. An example(E)... application test -check../test/main.cxx private macro data_file "/afs/cern.ch/atlas/offline/data/bmagatlas02.data” macro test_pre_check "ln -s $(data_file) test.dat" macro test_check_args "test.dat" macro test_post_check "/bin/rm -f test.dat" macro test_dependencies MagneticField The following macro definitions are private to this package. Client packages do not inherit these. The requirements file

15. An example(F)... application test -check../test/main.cxx private macro data_file "/afs/cern.ch/atlas/offline/data/bmagatlas02.data” macro test_pre_check "ln -s $(data_file) test.dat" macro test_check_args "test.dat" macro test_post_check "/bin/rm -f test.dat" macro test_dependencies MagneticField Define data file to be used in the test procedure. The requirements file

16. An example(G)... application test -check../test/main.cxx private macro data_file "/afs/cern.ch/atlas/offline/data/bmagatlas02.data” macro test_pre_check "ln -s $(data_file) test.dat" macro test_check_args "test.dat" macro test_post_check "/bin/rm -f test.dat" macro test_dependencies MagneticField These three standard make macros provide the parameters for the test procedure The requirements file

17. An example(H)... application test -check../test/main.cxx private macro data_file "/afs/cern.ch/atlas/offline/data/bmagatlas02.data” macro test_pre_check "ln -s $(data_file) test.dat" macro test_check_args "test.dat" macro test_post_check "/bin/rm -f test.dat" macro test_dependencies MagneticField Assure that MagneticField target is always built before the test target. This is useful when using the -j option of gmake The requirements file

18. how to use CMT One first has to setup CMT in order to gain access to the various management utilities, using for example the shell command: csh> source /lal/CMT/v1r14/mgr/setup.csh csh>cd /home/tengt/mydev/Foo/v1/cmt csh>vi requirements csh>cmt config csh>source setup.csh csh>gmake The most useful commands > cmt create [ ] > cmt show macro(s), set(s), constituent(s), uses, packages, versions, … > cmt broadcast [ ]