I just encountered a problem with inconsistent file names in CLHEP, and not sure if it’s a legitimate bug or what. The program I was trying to compile had an include
#include "CLHEP/Random/DoubConv.h". This worked fine for an installation where CLHEP was built and installed along with geant.
However, with a “system” CLHEP build, in particular the LCG releases at
/cvmfs/sft.cern.ch, that file is named
DoubConv.hh, even though its contents appear to be identical. I was able to make my build work with symlinks and adding include paths, but I’d like to know if there’s a better fix, or something I’m missing
Yes, the names of that one file are different (and apparently always have been different!) between the external CLHEP installation and Geant4’s subset.
The file is an “internal use only” file used by CLHEP’s random number generators (RandGaussQ, RandBinomial, and others). It may be exposed if an external library (such as G4CMP) implements a random number generator using the CLHEP generators as a guide.
This inconsistency is fixed in version 22.214.171.124 of CLHEP
Side question. I used a preprocessor option to work around this in the code where I introduced the problem. Does CLHEP have a preprocessor variable analogous to the awesome
G4VERSION_NUMBER that I can use to to maintain compatibility with the different cases?
I’m not sure there exists a preprocessor flag defined, but with:
std::string version = CLHEP::Version::String();
you should be able to have back the version number.
That can’t be used in a preprocessor
#if expression, which means it can’t be used to decide which filename string should be used for a
#include. Which means it will now be impossible (starting with CLHEP 126.96.36.199) to write code involving CLHEP/Random/DoubConv that is usable with Geant4 whether the internal or external CLHEP was chosen at installation time.
You can still use
G4VERSION_NUMBER associated with the usage of the external CLHEP 188.8.131.52 to identify the proper