CMake in Gaudi/LHCb F.A.Q.

This page will be populated with Frequently Asked Questions concerning the CMake configuration of Gaudi/LHCb based projects.

Add your own Question

Did you not find the answer you were looking for? If not please submit your question here.

Current user-submitted FAQ's can be found here

Where do I find documentation?

• An introduction to CMake configuration for Gaudi-based projects at GaudiCMake315Configuration.
• A description of the tools that profit from the CMake builds is at SoftwareEnvTools
• For the more curious, documentation on CMake itself can be found at http://www.cmake.org/documentation/

I added a package (or source file) to my local project but it is not built. Why? What should I do?

The problem is that CMake caches the state of the local project on the first build or when a configuration file is modified. Unfortunately there is not reliable way to automatically detect additions to the local working directory, so if you add a .cpp file to a package or a package to the local project, CMake will not notice it. That is why you must add this source file to the list of sources in CMakeLists.txt or the package to the list of package in the CMakeLists.txt at the top-level of the project.

How do I run only a group of tests?

All tests are flagged by a name and a label (for example, in Gaudi, the tests GaudiKernel.QMTest and GaudiKernel.confdb have both the label GaudiKernel) and you can select tests to run by a regular expression that matches the name or the label:

• select a test by name

make test ARGS="-R <regex>"

• select a test by label

make test ARGS="-L <regex>"

where you have to replace with the regular expression matching your test.

You can get the list of tests with

make test ARGS="-N"

and the list of labels with

make test ARGS="--print-labels"

You can run several tests in parallel using the -j N option (where N is the number of concurrent tests to run):

make test ARGS="-j 8"

There's a new version of a data package available, why it is not picked up?

CMake caches some informations collected during the configure step, in particular those details that require expensive operations like looking for a file in several directories. The path of a data package (including its version number) is one of them. This approach has also the advantage of keeping the build/run time environment stable, but sometimes it's useful to refresh or the cached details.

The quickest way it to call

make purge

which performs a deep clean of the build directory, thus forcing CMake to start from scratch and look again for the data packages.

An alternative approach is to modify the CMake cache file (build.$BINARY_TAG/CMakeCache.txt) either with a text editor or with the user interface ccmake (ccmake build.$BINARY_TAG). Editing the CMake cache can be also useful to change, for example, the version of a data package to an older version instead of using the default one.