Skip to content
Snippets Groups Projects

Draft: "Modernize" CMake configuration

Closed Marco Clemencic requested to merge cmake-modernization into master

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

:warning: do not squash the commits in this MR as they are meant to pull original Geant4 history into this repository.

Merge request reports

Closed by Marco ClemencicMarco Clemencic 3 years ago (Dec 1, 2021 10:36am UTC)

Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • @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 use 10.6.patch02 (that is the official G4) and for LCG_100 we use v106r3p4

  • @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 use v10r7p3, while v107r3 would mean 107.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 to 10.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 of lhcbstacks (or may be Spack in the future), which is similar to what Linux distributions are doing too.

  • Marco Clemencic mentioned in merge request !79 (merged)

    mentioned in merge request !79 (merged)

Please register or sign in to reply
Loading