Hi
It could be fine to arrange to have a "geant4-config" program available (in the bin directory) after a G4 build and installation had been done.
This is needed for people that want to build a G4 app but by not using the G4 make system.
One painful point with G4 is that G4 can be installed with or without "global / granular" libs
(which is unique ! I don't know another software having two "lib flavors")
and with the includes "gathered in one include directory" or not. And this various cases definitely complicate the life of people in their build system to detect the various G4 installation cases.
I would suggest then that G4 comes with a "geant4-config" programs that provides the "right infos"
at least for :
geant4-config --cflags (or --incs)
geant4-config --libs
And then up to the geant-config program to look how G4 had been installed and then to return
the correct infos. For exa for "--libs" to return the "granular flavor" is the global libs are not here.
The "global flavor" if the granulars are not here. And probably the globals if both are here (because
the list of the globals is shorter).
And about the "--incs" then returns the "-I <install_path>/include" if existing, the "whole -I list"
in case a "gathering had not been done" and the G4 sources "are still around after installation", and "none" in case... nothing is found !
Having such program would be VERY helpful. (And, again, especially knowing that G4 is "special"
in the sens that it comes with two possible flavors of its libs and then installations).
(In fact, as a "xxx-conifg" program is a common practice in software, I hope to have not to argue
too much to convince the G4 team).
(Not so clear if the --incs, --libs should return the CLHEP infos. Probably not since CLHEP already
comes with a clhep-config).
(There is the entry 1218 of O.Lahaye that looks similar to this post, but not clear to me if the "pkg-config" mentioned here is the same than "having a geant-config". Then I prefer to have an explicit
entry for this issue).
Cheers. Guy
|