You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
The text was updated successfully, but these errors were encountered:
SuperNEMO would like to formally request that this be implemented by end of 2019 at the latest. It's going to be a critical need for us to test and validate new versions of Geant4.
Whilst the
Bayeux_mctools_geant4
extension library is built separately from the coreBayeux
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 splittingBayeux_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 forBayeux
andBayeux_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
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_geant4
installs 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
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.
The text was updated successfully, but these errors were encountered: