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?
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:
make test ARGS="-R <regex>"
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.