Draft: "Modernize" CMake configuration
This MR align the content of the LHCb Geant4 project with that of the official Geant4 repository, with the addition of LHCb patches, physics lists and tests.
The Geant4 version used as baseline is 10.7.3
Merge request reports
Activity
@gcorti, @dpopov, this is what I was proposing during our discussion.
The only problem I see with this change is that we should switch from our versioning scheme (
v107r3
) to the official Geant4 one (10.7.3
). I do not know exactly the impact this change would have on the deployment, but we can discuss the details.@clemenci, 'our' versioning is an extension of the official Geant4, i.e. v{G4-version}r{G4-patch}p{LHCb-build}
One other point to keep in mind is that for
Sim10
we use10.6.patch02
(that is the official G4) and for LCG_100 we usev106r3p4
@gcorti, I know the mapping between Geant4 tags and our vXrY versions. The problem is the mapping between vXrY I use in every other LHCb project. So if we take the CMake version from the official Geant4 sources and we map it to vXrY, for
10.7.3
we should usev10r7p3
, whilev107r3
would mean107.3
.When going from the current wrapper around the official Geant4 sources to just the official sources (plus patches, of course), the CMake version of the project jumps from
107.3
to10.7.3
.At the moment we do not care too much about the exact CMake version of a project, but we have to find how to handle the transition.
About 10.6, I can easily change the baseline of my merge request.
Sorry to be a bit dumb but what I don't understand is how we version the LHCb build, because we will need to at the minimum to match the LCG build - I know you are going to say that as long as it is compatible we will not need to but in production things must be fixed to ensure reproducibility. And more importantly if we deploy a patch to the code.
You are far from dumb, that's the problem I deliberately not mentioned as I'm still trying to figure it out.
Ideally I would add a
-lhcbN
to the official Geant4 tag we patch, similar to the way Linux distributions version their patches on top of the official versions of the software projects they include. This, however, does not participate in the version number seen by CMake, but it's not a big deal as we fix the versions we want in the stack by means oflhcbstacks
(or may be Spack in the future), which is similar to what Linux distributions are doing too.mentioned in merge request !79 (merged)