Skip to content

Feature Request: Split Mctools/Geant4 library into separate project  #31

Open
@drbenmorgan

Description

@drbenmorgan

Whilst the Bayeux_mctools_geant4 extension library is built separately from the core Bayeux library, testing new Geant4 versions requires one Bayeux install for each version of Geant4. Whilst that's reasonably straightforward, there could be a benefit in splitting Bayeux_mctools_geant4 code out of Bayeux into a separate repository/project that just builds that library.

From the developer/build perspective, the only change is the extra repository, and Bayeux_mctools_geant4 only has to depend on Bayeux and Geant4. No changes are needed to source code, and build scripts for Bayeux and Bayeux_mctools_geant4 would be simplified. It should also be quicker and easier to update the code for new Geant4 versions.

For clients of Bayeux, the only change needed would be how the package is found. For example, in SuperNEMO, we have

find_package(Bayeux REQUIRED geant4)

which would become something like

find_package(Bayeux REQUIRED)
find_package(Bayeux_mctools_geant4 REQUIRED)

The real advantage for clients would be that it would become easier to test and validate different Geant4 versions in this setup. By splitting out just the mctools-G4 interfaces, the client just needs one Bayeux install, and can add as many Bayeux_mctools_geant4 installs as needed for the Geant4 versions to be tested.

+- Bayeux-3.X/
     +- include/
     +- lib/
          +- libBayeux.so
+- MCGeant4/
     +- 9.6.4/
          +- libBayeux_mctools_geant4.so -> links to Bayeux-3.X, Geant4 9.6.4
     +- ...
     +- 10.5.0/
           +- libBayeux_mctools_geant4.so -> links to Bayeux-3.X, Geant4 10.5.0

For both experienced developers, and for deployment/packaging, this would save quite a bit of time and disk space, and any runtime/link issues should be easier to solve. In addition, if the client uses a dpp pipeline, they would only need to point the script to the appropriate module, which should make it easier to write validation pipeline scripts for running on clusters.

The above isn't critical, at least from SuperNEMO's side, but I think it would be a "nice to have" in the medium term. It's also a bit vague in overall requirements, so discussion is very welcome.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions