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?

Jenkins Build SUCCESS

Results 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 the SherpaTool library. Which is fine. But that is an extra feature that Sherpa_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 the Find<Generator>.cmake logic and the intermediate layer of Projects/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

closed

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 and Generators/<Foo>_i at the same time.
  • To develop the changes for Generators/<Foo>_i, you'd either temporarily add

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 into Projects/WorkDir/CMakeLists.txt after the find_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