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.
Whilst the
Bayeux_mctools_geant4extension library is built separately from the coreBayeuxlibrary, testing new Geant4 versions requires one Bayeux install for each version of Geant4. Whilst that's reasonably straightforward, there could be a benefit in splittingBayeux_mctools_geant4code 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_geant4only has to depend on Bayeux and Geant4. No changes are needed to source code, and build scripts forBayeuxandBayeux_mctools_geant4would 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
which would become something like
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_geant4installs as needed for the Geant4 versions to be tested.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
dpppipeline, 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.