Now that I'm back from my holiday, I thought this may be the best way to show developers in the generators group how they should handle it when they want to start using a new generator in their nightly. In this case OpenLoops. So first of all let me cc people who were on this e-mail thread earlier. @ewelina, @fsiegert, @chays, @temoskal.
To cut right to the chase, the way to build this development branch of mine is like this:
setupATLAS export LCG_RELEASE_BASE=/cvmfs/sft.cern.ch/lcg/releases asetup AthGenerationExternals,21.6,latest,slc6 --noLcgReleaseBase cmake ../athena/Projects/AthGeneration/
The important part here is that since OpenLoops is not being used by the nightly just yet, it is not yet installed together with the nightly under
/cvmfs/atlas-nightlies.cern.ch. So you have to be explicit during the environment setup that all LCG packages have to be picked up from their "original" location, from
At this point you've set up the whole AthGeneration project. Which, while not a huge project, does need a "proper" PC to build, lxplus doesn't really suffice for building the whole release. But... You can still at least start the development process on the new external. You can just build the package that you're modifying, together with everything that it depends on, with
make Package_Herwig7_i. This still needs to build a few things, but a lot less things than what's needed for the full release. Unfortunately this setup doesn't really allow you to do any runtime tests (for that you'd need to build the full release in this setup), but at least you can write some first pieces of code, merge that into the 21.6 branch, and once the next nightly is ready, you should be able to continue the development in the "regular way".
Now for the code:
- As we discussed via e-mails, I had to add an
OpenLoops.cmakefile to specify exactly which version of OpenLoops should be picked up by AthGeneration;
- I also had to fix a mistake in the package selection of the project which was giving a very annoying warning during the project's configuration. This one:
CMake Warning at /build/atnight/localbuilds/nightlies/21.6/build/install/AthGenerationExternals/21.6.11/InstallArea/x86_64-slc6-gcc62-opt/cmake/modules/AtlasInternals.cmake:1199 (message): Ignored these rule(s) while selecting packages to build: + Database/AthenaRoot/RootAuxDynIO Make sure that you didn't make a typo, and that there is no duplicate in: /build/atnight/localbuilds/nightlies/21.6/athena/Projects/AthGeneration/package_filters.txt Call Stack (most recent call first): /build/atnight/localbuilds/nightlies/21.6/build/install/AthGenerationExternals/21.6.11/InstallArea/x86_64-slc6-gcc62-opt/cmake/modules/AtlasFunctions.cmake:450 (atlas_print_unused_package_selection_rules) CMakeLists.txt:70 (atlas_project)
Which you can also see in the nightly: http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/gitwww/GITWebArea/nightlies/21.6/2019-09-20T2142/AthGeneration/x86_64-slc6-gcc62-opt/AthGeneration/cmake_config.log.html
(You guys should pay more attention to these things...)
- Then I cleaned up the CMake configuration of the
Herwig7_ipackage a bit. Things were a bit all over the place in there.
- And finally I added some dummy code to the C++ code to test that the library would make use of the OpenLoops header and library correctly.
Now... I meant this to serve as an example of what you guys may want to do to start using OpenLoops in the nightly. But you may very well just cherry-pick my commits into one of your feature branches (except for the very last one, which really shouldn't be used as-is), add a bit of C++ code on top of it, and open your own MR from such a feature branch. (And as I wrote earlier, once that is merged in, and a new 21.6 nightly is ready, you can continue to develop the code in the "usual way".)
Hope that this will clear things up a bit...