cmake: could not find TBB in ATLAS builds

With the current Gaudi master, we are seeing the following cmake configuration error in ATLAS:

-- Setting up LCG release using: /cvmfs/sft.cern.ch/lcg/releases/LCG_100_ATLAS_1/LCG_generators_x86_64-centos7-gcc8-dbg.txt
-- Found TBB: /cvmfs/sft.cern.ch/lcg/releases/LCG_100_ATLAS_1/tbb/2020_U2/x86_64-centos7-gcc8-dbg (found version "2020.2") 
[...]
-- Found ROOT: /cvmfs/sft.cern.ch/lcg/releases/LCG_100_ATLAS_1/ROOT/v6.24.00/x86_64-centos7-gcc8-dbg/cmake (found version 6.24.00)
-- Could NOT find TBB (missing: TBB_DIR)
[...]
-- The following REQUIRED packages have not been found:

 * TBB (required version >= 2019.0.11007.2)

This started appearing after !1209 (merged) got merged. My first suspicion was this is related to LCG_100, but it already happened on LCG_98.

cc @clemenci @akraszna

changed milestone to %v36r0

changed title from cmake: could not find TBB in ATLAS builds to cmake: could not find TBB in ATLAS builds with LCG_100

changed title from cmake: could not find TBB in ATLAS builds with LCG_100 to cmake: could not find TBB in ATLAS builds

changed the description

mentioned in merge request !1209 (merged)

I understand that you have a custom FindTBB.cmake in ATLAS, which should have precedence over the one in Gaudi.

If !1209 (merged) is causing the problem, it's probably due to the fact that the new version in Gaudi prefers the TBBConfig.cmake present in the latest TBB builds (I think post LCG 97a).

We had similar problems with CLHEP in LHCb when the FindXYZ.cmake and XYZConfig.cmake were mixed, and I see you have two calls to find_package(TBB) in the log.

One option is to make sure the ATLAS version of FindTBB.cmake is used instead of the Gaudi version.

Another option is to fix the Gaudi version so the it sets all the needed variables. We were missing TBB_LIBRARIES, so we added c2d53812 and we can add TBB_DIR too, or whatever else you need.

Very interesting. Marco gave a good hint, that I think the thing that broke our nightly is that we switched to LCG_100_ATLAS_1. Gaudi's CMake code was incompatible with our setup since long...

So what happens in the nightly is not that Gaudi would not be able to build itself correctly. That works fine, AthenaExternals builds the master version of Gaudi just fine.

http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/gitwww/experimentalWebArea/ardoc_web_areamastermasterGAUDI64BC7G8AthenaDbg/ARDOC_Log_2021-05-16T2101/ardoc_externals_build.html

It is once Athena tries to find the previously compiled Gaudi version, that things break.

Now... To tell the Gaudi build where to find all of its externals, we use this code:

https://gitlab.cern.ch/atlas/atlasexternals/-/blob/master/External/Gaudi/CMakeLists.txt#L12-151

I.e. we let Gaudi use its own modules as it wishes, we just direct those modules with a ton of cache variables to pick up the LCG externals. And this continues to work.

However, when we want to "find" Gaudi, we use a bit less code to sort out the externals for Gaudi's own CMake code. For that we use this:

https://gitlab.cern.ch/atlas/atlasexternals/-/blob/master/External/Gaudi/cmake/FindGaudi.cmake#L21-43

In the past it was enough that we would call find_package(TBB) "in our own code" (which would call on our implementation of FindTBB.cmake), since "our implementation" and "Gaudi's implementation" of this module were close enough. So the variables set up by the ATLAS module were enough for Gaudi's module to find TBB itself as well.

But as Marco wrote, with the new LCG version this seems to have changed. We'll need to tweak our FindGaudi.cmake module to deal with the "new situation" correctly. (I assume we'll just need to set the TBB_ROOT variable explicitly. I'll try that out today.)

Just to emphasize again (I only realized this later myself) that I don't think this is related to LCG_100. We saw the same problem in LCG_98 right after the changes to Gaudi's FindTBB module: http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/gitwww/experimentalWebArea/ardoc_web_areamastermasterGAUDI64BC7G8AthenaDbg/ARDOC_Log_2021-05-13T2101/ardoc_cmake_config.html

The day before the build was still OK: http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/gitwww/experimentalWebArea/ardoc_web_areamastermasterGAUDI64BC7G8AthenaDbg/ARDOC_Log_2021-05-12T2101/ardoc_cmake_config.html

Anyhow, it sounds like the problem is on the ATLAS side then, which we should fix before we can move to Gaudi v36r0.

mentioned in merge request atlas/atlasexternals!840 (merged)

Luckily the fix is as simple as atlas/atlasexternals!840 (merged). (With that included I can configure the Athena build against Gaudi master successfully, and even build some packages. I didn't try building the whole release though.)

mentioned in merge request atlas/athena!43601 (merged)

mentioned in commit atlas/athena@c072bdeb

Thanks Attila. I confirm it works now.

closed

mentioned in commit amoreira/athena@fef9609b

mentioned in commit sawyer/athena@9b6deed1

mentioned in commit ladamczy/athena@41458341

mentioned in commit atlas/athena@024e9573