Microsoft Project Exported Information

LHCb comments to the SCRAM/CMT evaluation report produced for the LCG project

David Quarrie and Christian Arnault have already pointed out a number of inaccuracies in the report concerning comments made about CMT. We will not repeat these here.

We appreciate there are nice features in SCRAM that we can benefit from, such as a very good web-based interface and the concept of projects. However there are a number of apparent differences in the features of both tools that have direct consequences for the way in which we manage software releases in LHCb and we would like to draw attention to them here:

Using CMT the code does not need to be in a src directory. In fact in LHCb we use this feature extensively to structure our code.
CMT can build several libraries and applications in the same package, whereas SCRAM cannot. LHCb developers use this feature to keep in the same package the component library, the link library and a test application.
CMT builds Unix makefiles and Windows nmake and msdev projects for libraries and applications. LHCb developers do not write makefiles on Unix nor on Windows, they rely on CMT.
CMT does reveal cyclic dependencies. This feature helps developers to structure their projects. Their is no built-in feature in SCRAM to reveal cyclic dependencies.
CMT does calculate the building order from the requirements files, SCRAM takes it from the project BuildFile provided by the developer. LHCb developers rely on CMT to build a project in the right order.
Applications built using CMT can be run from anywhere.
CMT requires one requirements file per package. Most of the packages in a SCRAM project contain a BuildFile, and a project contains a config directory to hold a BootStrapFile, the BuildFile, the requirementsDoc and all the makefiles required to build the project (more than 20 files in COBRA). LHCb software uses heavily the pattern facility built in CMT to write a package requirements file: some templates are available on CVS.
We have found these features that allow packages to be created easily and automatically gives an enormous advantage in that developers are not required to become CMT experts. Below we show some examples which illustrate this. Developers can check out the template they need, replacing the package name in italic by their own package name and adding the list of dependencies as CMT "use" statements.

component library package

linker library package

two-library package

package Mycomponent
version v1
branches Mycomponent doc src cmt

# add necessary "use" statements

#build a component library
library Mycomponent ../src/*.cpp
apply_pattern component_library \ library=Mycomponent

private
include_dirs $(MYCOMPONENTROOT)

package Mylinklib
version v1
branches Mylinklib doc src cmt

include_dirs $(MYLINKLIBROOT)

# add necessary "use" statements

#build a linker library
library Mylinklib ../src/*.cpp
apply_pattern linker_library \ library=Mylinklib

package Mytwolibs
version v1
branches Mytwolibs doc src cmt

include_dirs $(MYTWOLIBSROOT)

#add necessary "use" statements

#build a linker library
library MytwolibsLib ../src/Lib/*.cpp

#build a component library
library Mytwolibs ../src/component/*.cpp

apply_pattern component_library \
library=Mytwolibs
apply_pattern linker_library |
library=MytwolibsLib

CMT does not impose that the experiment's software is organised in one releasable unit. The fact that the ATLAS organization was inherited from the use of SRT in ATLAS may explain why they chose a different approach.
- in LHCb we release different projects:
  - Gaudi
  - LHCb kernel (based on a specific Gaudi version)
  - detector specific code (based on a specific LHCb kernel version)
  - visualization (based on a specific detector code version)
- From these releases we can build different applications
  - Gauss simulation program
  - Brunel reconstruction program
  - DaVinci analysis program
  - Panoramix visualization program

Concluding remarks

For a more complete evaluation it would be useful to consider the following :

an assessment of the impact on the (non-expert) user as opposed to the (expert) developer.
an assessment of the current usage of the tools and how they are to be maintained in the long-term.
an assessment of the ability to use these tools on different platforms currently and how easily this could be improved if required.

The authors of the evaluation made available the test versions they have built with the tools. Unfortunately the Athena example built with SCRAM does not work properly and the IGUANA example is not readable because of 'permission denied'.