Use cmake targets

Description

• Use cmake targets instead of separate usage of libraries/includes. This allows fro a much cleaner approach to the use of dependencies, allows for flag incorporation into the targets, etc.
• Add some minimal versions for ROOT, Openloops, etc.

Test Plan

Compilation should pass.

Additional Checklist Items

• I have updated documentation as needed No action needed.
• I considered if this should be cherry-picked/ported somewhere else (rel-2-x or master), and if yes, opened a corresponding issue or MR No action needed.

added 1 commit

• 42bffd2f - Update FindRivet.cmake

Compare with previous version

added 2 commits

• e7d725c6 - Fix spelling
• bc9b8210 - Merge branch 'use_cmake_targets' of gitlab.com:sherpa-team/sherpa into use_cmake_targets

Compare with previous version

added 1 commit

• b0d22d30 - Update CMakeLists.txt

Compare with previous version

added 1 commit

• 6e0edeab - Use the found variable

Compare with previous version

added 1 commit

• b7456f35 - Fix mkhtml option

Compare with previous version

added 1 commit

• 419e0aeb - Fix mkhtml option

Compare with previous version

added 1 commit

• e46ec7e3 - Fix

Compare with previous version

added build-system enhancement labels

added 1 commit

• 840d8f88 - Remove Rivet4 variable

Compare with previous version

added 1 commit

• f1f20d70 - Remove Rivet4 variable

Compare with previous version

mentioned in merge request !919 (closed)

added 3 commits

• f1f20d70...c8895a14 - 2 commits from branch master
• ea2c2d0c - Merge remote-tracking branch 'upstream/master' into use_cmake_targets

Compare with previous version

assigned to @andriish

requested review from @Reichelt, @ebothmann, and @fsiegert

added 5 commits

• ea2c2d0c...f5cec141 - 4 commits from branch master
• 39790e5d - Merge remote-tracking branch 'origin/master' into use_cmake_targets

Compare with previous version

Hi @Reichelt, @ebothmann, @fsiegert, can anyone review it? THe changes are really technical.

Andrii

Hi @andriish,

Thanks for the merge request. Since I'm not an expert in cmake, can you explain to me the advantages that you list? Correct me if I'm wrong, but I see that this is adding quite a few lines and complexity to our cmake setup and I wonder whether there is any "functionality" that makes this worth it.

Best,
Frank

Hi @fsiegert,

you are right, some explanations can be useful.

Why targets are better?

Targets incorporate everything what is needed from the dependency -- the list of link libraries, list of flags, the list of includes, etc. This means instead of writing 2-3-5 lines with target_link_libraries target_include_directories etc only one addition MYLib::MYLib is needed. E.g. in this approach SHERPA is not required to know what C++ standard is required by Rivet or other lib.

This means much cleaner code on the "user" side. So the main idea is to move the "complexity" from the CMakeLists.txt into the "Find" modules.

Now about the complexity in the Find modules. This "complexity" is always a boilerplate code, which is much easier to maintain in case of any changes in the dependencies. E.g. you can see that all the logic related to the Rivet versions is now in one place. There are also less obvious added benefits: the modules are reusable and independent enough to be updated by anyone. Even by ChatGPT .

Andrii

P.S. Also, in this MR the changes to the modules also include some version treatment.

removed review request for @Reichelt and @ebothmann

Thanks a lot for the explanations @andriish! This looks much neater with the Find modules. Just to make sure I understood correctly: In a line like

target_link_libraries(SherpaRivetAnalysis PRIVATE Rivet::Rivet HepMC3::HepMC3)

• The Rivet::Rivet means it should look for build and linker settings in the FindRivet.cmake (which it knows about via the set(CMAKE_MODULE_PATH ...) in our top-level CMakeLists.txt.
• But where does it look for HepMC3::HepMC3 since we don't have a FindHepMC3.cmake -- is that coming from a file bundled with the HepMC3 installation?