fix: CMake Code Usage Fix, main branch (2026.02.24.)

[krasznaa]

Made sure that CMake would always select the find-modules present in cmake/ over modules provided by either CMake or the parent project that builds Acts.

--- END COMMIT MESSAGE ---

I bumped into this as part of: https://gitlab.cern.ch/atlas/athena/-/merge_requests/86291 That since AthenaExternals also provides a Findonnxruntime.cmake module (https://gitlab.cern.ch/atlas/atlasexternals/-/blob/main/External/onnxruntime/cmake/Findonnxruntime.cmake?ref_type=heads) that behaves differently from the one provided by this project, using FetchContent on top of the Athena project was not working out of the box. 😦

Pinging @murnanedaniel and @benjaminhuth.

[krasznaa]

Though, thinking about it, this may not be a perfect setup either. 😦

You see, anything that Acts needs from LCG in the ATLAS build (like Boost for instance) does need the find-module provided by ATLAS. 🤔 So maybe we just need to accept that the build would be this fragile as part of https://gitlab.cern.ch/atlas/athena/-/blob/main/Projects/WorkDir/ActsOverride.cmake?ref_type=heads. 😦 I wonder if it's just Findonnxruntime.cmake that's duplicated like this between Acts and AtlasLCG. 🤔 I'd be very okay with somebody other than me looking this up / sorting this out.

@paulgessinger, let me tag you as well...

[benjaminhuth]

Yeah I think the root cause of this that there is no general way on how to configure ONNX in cmake, but that each package needs to provide its on finding which are not necessarily compatible...

I think the other possible solution would be to align the cmake finding code, but this is also not great since this could diverge over time again... So probably its the best solution to just hardcode it in the ATLAS build...

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[andiwand]

closing due to inactivity

[krasznaa]

I forgot about this one. 😦 But as it happens, it's sort of related to our most recent issue with Acts+GNN. 🤔

https://gitlab.cern.ch/atlas/atlasexternals/-/merge_requests/1350

I'm curious how "GNN people" want to solve this. As unless we do something, the Athena+Acts builds will not work with GNN enabled. 🤔

[krasznaa]

Yeah I think the root cause of this that there is no general way on how to configure ONNX in cmake, but that each package needs to provide its on finding which are not necessarily compatible...

I think the other possible solution would be to align the cmake finding code, but this is also not great since this could diverge over time again... So probably its the best solution to just hardcode it in the ATLAS build...

As it happens, and as described in https://gitlab.cern.ch/atlas/atlasexternals/-/merge_requests/1350#note_11325625, "good" ONNXRuntime installations should provide their own onnxruntimeConfig.cmake . So it would seem best to migrate Acts to using that.

[benjaminhuth]

I forgot about this one. 😦 But as it happens, it's sort of related to our most recent issue with Acts+GNN. 🤔

Hmm but this was only present with the CONFIG mode forced on, right? So the MR of concern could be fixed by fixing the Boost discovery, right?

Regarding ONNX: I think you are right, we should check if the onnxruntimeConfig.cmake shipped with latest builds is working well, and retire our find-module. I actually was not aware that they now ship the cmake config, this must have been changed somewhat recently? Does Athena use it?

For now I would try to not let the perfect be the enemy of the good and do all of this step by step