This is going to be a big update...
Ever since CMake 3.15.0 all of our projects generate a warning like:
CMake Warning (dev) in CMakeLists.txt: No project() command is present. The top-level CMakeLists.txt file must contain a literal, direct call to the project() command. Add a line of code such as project(ProjectName) near the top of the file, but after cmake_minimum_required(). CMake is pretending there is a "project(Project)" command on the first line. This warning is for project developers. Use -Wno-dev to suppress it.
atlas_project(...) function was written with the idea back in the day that it would call project(...) itself. Hiding that function all together from the user.
We need to stop doing that. But the silver lining is that the "old" setup came with a couple of its own issues as well, which we should now be able to solve cleanly with this re-design. (Most of all it should allow us to make
FindGaudi.cmake a lot more robust than it is now...)
As a first thing, I updated the
AthDerivationExternals project to demonstrate what project configurations would need to look like in the future. As you can see there, the project's name and version number is now hardcoded at the top of the file. I was quite worried about this for a while, because I wasn't sure how we could keep the option to allow users to override the version of the projects from the command line. (This is a very important feature for the external projects. As their exact version numbers are always determined by the version number of the "main" project that builds them.) The good news is that this is actually possible to do out of the box.
cmake -DCMAKE_PROJECT_VERSION=22.0.9 ... ../atlasexternals/Projects/AthDerivationExternals/
In such a setup the version number specified on the command line will "win out" over the number specified in the
version.txt files all together. Replacing them with specifying the project versions in the main
CMakeLists.txt files of the projects. (This will be a change for the release managers, so I'm open to feedback on this.)
It might be worth discussing this a bit in a Core SW meeting before I would push it in.