Support for building G4HepEm without Geant4 #102
Conversation
Make structure clearer and in line with that of other components.
Use cases for G4HepEm not requiring use of Geant4 have recently been identified, only needing the data and run components. Generation of data would still be required, but can be persisted separately and read in without needing Geant4 via G4HepEm's JSON persistency. Add CMake option to enable support for Geant4, defaulting to ON to match current behaviour. Update build so that when this is OFF, it - Does not build the G4HepEm and G4HepEmInit components - Finds the CLHEP package to support random number generation in G4HepEmRun - Sets the G4VERSION_NUM to 1100 (TODO: make selectable) - Add a "geant4" component in installed CMake config file to allow detection of this feature - Adapt G4HepEm_LIBRARIES for both build variants - Do not build tests even when testing enabled as they currently all require Geant4 or G4HepEm's support for it
|
Looks good so far. Regrading your point 1. on the These headers, together with the
The client application would not depend on I have an application that works very nicely like this now (with my locally modified We might think to have a nicer solution in the future for providing the actual random engine to |
The intent of building G4HepEm without Geant4 is to remove any external dependency, leaving it to the consumer to implement the core random number engine and wrapper functions. Remove CLHEP dependency when building without Geant4, removing the CPU-side implementation file with G4HepEmRandomEngine's flat and flatArray member function definitions. Link g4HepEmRun shared library with dynamic_lookup of undefined symbols on Darwin only. Document reason for this and potential issues. Update documentation of G4HepEmRandomEngine noting requirements for users on implementing the host-device engine(s) and member functions.
|
Thanks @mnovak42, that clarified things for me! Latest changes should remove the CLHEP dependency when building without Geant4. I've updated the docs for |
Following discussion with @mnovak42, this is a first pass at supporting building G4HepEm without its components that depend on Geant4, and hence Geant4 itself. There are no changes to code itself, just to organisation and build scripts:
G4HepEm/{include, src}directories and the build of theg4HepEmlibrary are moved to a subdirectoryG4HepEm/G4HepEmto bring this in line with the other components and to simplifyG4HepEm/CMakeLists.txtG4HepEm_GEANT4_BUILDis introduced and set toONby default to retain existing default behaviour. When set toOFFthe build:G4HepEmRunG4VERSION_NUMmacro needed in a couple of placesI've tested build/use with this option ON/OFF and with CUDA ON/OFF, and things seem to work o.k. though this probably hasn't covered all possibilities.
The two issues to think about with the above are:
G4HepEmRandomEngine.hhon the random engine typeinstead of hiding via a
voidpointer. When Geant4 isn't used, it'd be up to the user to provide one, which they could also do in the Geant4-enabled case, and we could also provide a default.G4VERSION_NUMmacro inG4HepEmRunwhen Geant4 isn't used. It's hardcoded for now, but could be made selectable.