Skip to content

ROOT Build Re-Design, master branch (2020.11.30.)

This is quite a big shift in how the external packages would "find each other" during the build. Until now if "package A" needed "package B" for its build, it would always pick up the build results of "package B" from ${CMAKE_BINARY_DIR}/${ATLAS_PLATFORM}. But this never worked quite perfectly with ROOT, and since ROOT 6.22/00 that setup just didn't work with incremental builds at all. 😦

To overcome this, the ROOT build must not pick up anything from ${CMAKE_BINARY_DIR}/${ATLAS_PLATFORM} anymore. But to avoid hardcoding details about the internals of every package that ROOT depends on into External/ROOT, I switched to using imported targets for communicating the locations of build results between the packages.

As a very first thing I taught the custom find-modules of AtlasLCG to set up imported targets (with names <pkgName>::<libName> and <pkgName>::<exeName>) for the executables and libraries that they found. This shall also be useful later on when/if we decide to move to using imported targets for setting up the build of the offline projects against external libraries.

After that I taught every package that External/ROOT depends on to set up imported targets with the same name that would be created by the find-module in AtlasLCG that's meant to find them. (Except for External/PyAnalysis. Since there is no single module finding the results of that package. So there I just used a custom/dummy imported target.)

With all this in place, ROOT seems to happily re-build itself in incremental steps. Even better than it used to do before. So I also re-enabled the "forceconfig" build step of it, to make sure that incremental builds would always configure/build ROOT against the correct externals.

This was all needed to create a fix for the CI issues discussed in ATLINFR-3852.

Merge request reports