Update Sherpa lib dependencies for new function used in Sherpa_i since Sherpa 2.2.4.
The function used in https://gitlab.cern.ch/atlas/athena/blob/master/Generators/Sherpa_i/src/Sherpa_i.cxx#L167 is defined in libSherpaTools.so, which is thus here added to the compulsory components of FindSherpa.cmake.
Local builds of Athena would otherwise always fail due to
[ 41%] Linking CXX shared module ../../x86_64-linux6-gcc62-opt/lib/libSherpa_i.so
CMakeFiles/Sherpa_i.dir/src/Sherpa_i.cxx.o: In function `Sherpa_i::genFinalize()':
/scratch/athena/Generators/Sherpa_i/src/Sherpa_i.cxx:141: undefined reference to `SHERPA::operator<<(std::ostream&, SHERPA::Variations const&)'
collect2: error: ld returned 1 exit status
Surprisingly it seems like the central release build succeeded so far, probably because it is using lazy linker settings?
Merge request reports
Activity
Jenkins Build SUCCESSResults available at: Jenkins [AE-MERGE-REQUEST #429]
Hi Frank,
I'm not absolutely convinced that this update is the right thing to do...
The "compulsory components" of an external are supposed to be the minimum set of libraries that need to be linked against to get the "core functionality" of that external. So, for instance if the external has 5 libraries in total, but the 2 core ones "can't live without each other", then those 2 would be set as the "compulsory components" of the external.
In this case it seems that
Sherpa_i
is using an operator that is implemented as part of theSherpaTool
library. Which is fine. But that is an extra feature thatSherpa_i
uses. So it should just declare itself that it needs that extra library.And that's exactly what happens.
https://gitlab.cern.ch/atlas/athena/blob/master/Generators/Sherpa_i/CMakeLists.txt#L21
Which branch were you trying to build
Sherpa_i
out of? Against which nightly?Cheers, Attila
Okay, well, 21.0 doesn't have that setup.
https://gitlab.cern.ch/atlas/athena/blob/21.0/Generators/Sherpa_i/CMakeLists.txt
So you should rather update the CMake configuration of
Sherpa_i
in 21.0 in the same way as it is set up in master.Hi Attila,
thanks for the quick and helpful reply!
Good point on this kind of dependency belonging into the Sherpa_i/CMakeLists.txt. I was indeed building based on 21.0 so I didn't have this change which was introduced in master a year ago. I'll cancel this merge request for atlasexternals then.
So we debugged the same problem twice, which is not ideal. We are still getting set up with the Git workflow for generators, so maybe you can tell me what would have been the correct way for such a change to automatically propagate from master to 21.0? Should I have requested a cherry-picking somewhere, or should it come through sweeps automatically (which I think we are behind with on the generators side)?
On a similar note, I don't know if you have seen my mail going into a similar direction: For most of our generators the atlasexternals
Find<Generator>.cmake
module is only used in exactly one place, namely in<Generator>_i
. To reduce the maintenance load on you guys and increase the agility on our side I propose to move all of theFind<Generator>.cmake
logic and the intermediate layer ofProjects/Athena/externals/<Generator>.cmake
into the<Generator>_i/CMakeLists.txt
in such cases. We had discussed this already quite a bit with @fwinkl and thought it would be a solution to all of the problems that had lead to the non-ideal split of the build-logic into three packages. Do you see any disadvantages to this approach?Best, Frank
Hi Frank,
You bring up a large number of questions here...
- Changes made in the master branch are not cherry-picked anywhere automatically. The idea is that the master branch is the cutting edge version of the code, which in most cases should not be pushed back into our production branches. In this case I can only suggest that you should check the code of the master branch whenever you come across some weird issue in 21.X.
- It's a hard question about the find-modules. The current logic, where we have all the find-modules for LCG packages in one place, is one that I like a lot. Especially because the implementation of all of these find-modules should be kept in sync. (Sometimes we make some larges changes to how these should behave, all at once.) I see your point that making changes in both this repository and in 'atlas/athena' is more painful than just making a change in 'atlas/athena'. But I'd like to see us first having a lot of trouble because of this current setup before we would move these modules into the main repository.
- For the "version files" I always had the following idea:
- In order to update the package in the repository, with git you can just set up a single MR that changes both
Projects/Athena/externals/<Foo>.cmake
andGenerators/<Foo>_i
at the same time. - To develop the changes for
Generators/<Foo>_i
, you'd either temporarily add
- In order to update the package in the repository, with git you can just set up a single MR that changes both
set( <FOO>_VERSION "1.2.3" ) set( <FOO>_ROOT ... )
lines to
Generators/<Foo>_i/CMakeLists.txt
, being careful not to commit these lines, or you'd temporarily add these same lines intoProjects/WorkDir/CMakeLists.txt
after thefind_package( Athena )
call. This will allow you to test out new versions of the generators, and then set up merge requests for changing the nightly.I admit, this is not the simplest working mode ever, but I thought it could be acceptable.
Cheers, Attila