Inconsistent file names in CLHEP?

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 2.4.4.1 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 2.4.4.1) 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 2.4.4.1 to identify the proper #include.