search

FairRootGroup / FairRoot

C++ simulation, reconstruction and analysis framework for particle physics experiments
http://fairroot.gsi.de
Other
57 stars 96 forks source link

Replace deprecated APIs from FairMQ and Geant4 #1504

Closed karabowi closed 5 months ago

karabowi commented 5 months ago

Addresses issue #1501 in FairMQ part. Also Geant4 deprecates functions like Set...() in favor of Propose...().

Checklist:

rbx commented 5 months ago

I attempted to test this on my machine, but I get the same compilation error as on cdash: https://cdash.gsi.de/viewBuildError.php?buildid=447412 (the ‘class G4FastStep’ has no member named ‘ProposePrimaryTrackProperTime’; did you mean ‘ProposePrimaryTrackFinalProperTime’ ones) With FairSoft jan24.

rbx commented 5 months ago

As for the FairMQ-related changes, they look good to me and get rid of the warnings. Indeed, as Dennis said, GetChannels is only available since FairMQ v1.5.0, so that should be bumped.

dennisklein commented 5 months ago

As for the FairMQ-related changes, they look good to me and get rid of the warnings. Indeed, as Dennis said, GetChannels is only available since FairMQ v1.5.0, so that should be bumped.

Whether to bump the required FairMQ version should depend on the range of FairSoft versions intended to be supported!

karabowi commented 5 months ago

You are all right. Since we want to have the v19 also working with nov22, we should not bump the FairMQ version, but rather deal with the deprecation warning other way. Closing this PR and waiting for Dennis to deal with issue https://github.com/FairRootGroup/FairRoot/issues/1501.

dennisklein commented 5 months ago

Btw, the analog question is also open regarding the minimum required ROOT version. Since we switch to discover ROOT via its CMake package, we implicitely bump the min version to the first ROOT release that ships a CMake package. However, in our CMake we also state some version.

In general, the version combinatorics are poorly managed in FairRoot, imho we should improve here and clearly document which versions FairRoot intends to support (for all deps). Not just in terms of FairSoft, technically, FairRoot should not need to know about FairSoft, meaning we should resolve the required versions (which may be defined via FairSoft) to a per package term. At least, if we ever want to achieve regular packagability of FairRoot.