Project build flags are difficult to control (2024.05.29.)

[krasznaa]

@fwinkl discovered in the debug Athena nightlies that any jobs using Acts (executed from an installation of Athena sitting on CVMFS), would produce errors like:

...
profiling:/build1:Cannot create directory
profiling:/build1/atnight/localbuilds/nightlies/Athena/24.0/build/build/AthenaExternals/src/Acts-build/Core/CMakeFiles/ActsCore.dir/src/AmbiguityResolution/GreedyAmbiguityResolution.cpp.gcda:Skip
profiling:/build1:Cannot create directory
profiling:/build1/atnight/localbuilds/nightlies/Athena/24.0/build/build/AthenaExternals/src/Acts-build/Core/CMakeFiles/ActsCore.dir/src/Visualization/EventDataView3D.cpp.gcda:Skip
profiling:/build1:Cannot create directory
profiling:/build1/atnight/localbuilds/nightlies/Athena/24.0/build/build/AthenaExternals/src/Acts-build/Core/CMakeFiles/ActsCore.dir/src/Visualization/GeometryView3D.cpp.gcda:Skip
profiling:/build1:Cannot create directory
profiling:/build1/atnight/localbuilds/nightlies/Athena/24.0/build/build/AthenaExternals/src/Acts-build/Core/CMakeFiles/ActsCore.dir/src/Visualization/IVisualization3D.cpp.gcda:Skip
profiling:/build1:Cannot create directory
profiling:/build1/atnight/localbuilds/nightlies/Athena/24.0/build/build/AthenaExternals/src/Acts-build/Core/CMakeFiles/ActsCore.dir/src/Vertexing/VertexingError.cpp.gcda:Skip
profiling:/build1:Cannot create directory
profiling:/build1/atnight/localbuilds/nightlies/Athena/24.0/build/build/AthenaExternals/src/Acts-build/Core/CMakeFiles/ActsCore.dir/src/Vertexing/FsmwMode1dFinder.cpp.gcda:Skip
...

For the original report (visible just to ATLAS members), see: https://its.cern.ch/jira/browse/ATLINFR-5390

This is coming from the very rigid setup in: https://github.com/acts-project/acts/blob/main/cmake/ActsCompilerOptions.cmake Specifically from using --coverage in Debug builds.

That configuration would need some serious re-thinking, as it must be possible for the clients of the project to fine-tune how the project would be built. Including making changes to the flags that Acts's developers came up with. (Otherwise building on a platform on which the code was not tested, becomes even more of a pain.)

I have some ideas myself of how to re-design the C++ flag configuration of the project. But wanted to set up an issue about it first.

[AJPfleger]

Another discussion/suggestion on the flag configuration can be found here:

• feat: Add CMake presets #3135

However, I think the presets were only intended for ACTS-flags. But I can see that also C++ flags could be handled on a higher level and also have more presets for those?

[krasznaa]

Hmm... I was not even thinking about presets here. 🤔

First off we need to make sure that all these flags could be controlled "from the outside" using cache variables. In the ATLAS code we do this like:

https://gitlab.cern.ch/atlas/atlasexternals/-/blob/main/Build/AtlasCMake/modules/AtlasCompilerSettings.cmake?ref_type=heads

I.e. we declare ATLAS_CXX_FLAGS_RELEASE, etc. as cache variables, with default values. And these get added to CMAKE_CXX_FLAGS_RELEASE, etc. by default. This allows clients to control both ATLAS_CXX_FLAGS and CMAKE_CXX_FLAGS from the outside to their heart's content.

So on first order I'd just want to make everything in https://github.com/acts-project/acts/blob/main/cmake/ActsCompilerOptions.cmake into cache variables, with only tiny changes in the code's logic.

I'll try to find some time for this in the non-too-distant future, then we can discuss about my proposal on the PR that I'll open.

[paulgessinger]

Seeing this now. This was of setting the compiler flags has been there for a long time, and is likely overdue for an overhaul. I would be in favor trying to contain changes to ActsCompilerOptions.cmake, however.

[github-actions]

This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.