Description
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.