feature request: Get installed FairRoot version as git identifier from derived projects

[TobiasStockmanns]

To be able to check what version of FairRoot was used for the simulation of data it would be good to get the git version of the installed FairRood code (e.g. somehting like the output of git describe --dirty) from the installation folder.

[ChristianTackeGSI]

As a first remark, about the "offcial version string":

With "official version string", I mean something like "19.0.0". So for FairRoot this is the version as coded in the main CMakeLists.txt. That's not the git commit hash, obviously.

• There is a FairVersion.h in include/ in the install tree. It has a preprocessor define FAIRROOT_VERSION in it. So in your C / C++ code you should be able to #include <FairVersion.h> and then use FAIRROOT_VERSION to get the FairRoot-version at compile time.

  It also has a FAIRROOT_GIT_DATE definition. But that doesn't look too useful on my spack based install tree.

• fairroot-config --version also can be used to get it.

  (PandaRoot has some fallback CMake code to set FairRoot_VERSION from fairroot-config.)

• FairRoot 19's CMake package now exports a FairRoot_VERSION variable with the numeric version as a string (i.e. 19.0.0).

  This variable will be available straight after find_package2(PUBLIC|PRIVATE FairRoot).

[ChristianTackeGSI]

Possible TODO for the "official version string":

• Bake it into the library and provide an accessor function for it.
• Decide on the name for the accessor function. I don't know, whether there is an established standard for this kind of interface by now.

That way, one can query the FairRoot version at runtime. (So if the installed version is different from the one, that an application was built against.)

[ChristianTackeGSI]

Possible TODOs for a git commit hash based version string:

• Decide on a current format for it.

  I would for example include the "official version number string" from above in it.
  It could also contain the date of the git commit.

• Declare it opaque. That is: We try to make it useful for humans for traceability. But we do not promise to keep the format always the same. So parsing it from code is an operation that might fail in any way at any point in time without prior notice.

• Export it through a useful set of methods.

  Options to consider 1) cmake package 2) header file 3) baked into library 4) fairroot-config
  (I personally think, that (4) is not needed when all other options are in place.)

[dennisklein]

Possible TODO for the "official version string":

• Bake it into the library and provide an accessor function for it.

• Decide on the name for the accessor function. I don't know, whether there is an established standard for this kind of interface by now.

That way, one can query the FairRoot version at runtime. (So if the installed version is different from the one, that an application was built against.)

If I understand you correctly, this is what ABI versioning is for. Currently, the ABI version := API version (for all of our projects) and expressed by having versioned shared library symlinks in the install tree an application should link against. I don't think we can afford to or have an urgent need to harden the libraries further in that regard. Having the "official version string" in a header file and assuming that a user is not mixing headers from one FairRoot install tree with libs from a different FairRoot install tree must be enough IMHO.

[dennisklein]

Possible TODOs for a git commit hash based version string:

• Decide on a current format for it.
  I would for example include the "official version number string" from above in it.
  It could also contain the date of the git commit.

In other repos we generate a git-based version string via git describe --tags --dirty --match "v*" which results in something like

v18.4.1-121-g5b8dd9d0e[-dirty]
<tag>-<# commits since tag>-g<short commit hash>[-dirty]

-dirty is appended if there uncommitted changes in the source tree.

However, this may not be possible depending on how FairRoot is packaged ...

• Export it through a useful set of methods.
  Options to consider 1) cmake package 2) header file 3) baked into library 4) fairroot-config
  (I personally think, that (4) is not needed when all other options are in place.)

Let's simply match all the places that also provide the "official version string"

[ChristianTackeGSI]

First step:

Adding fair_get_git_version() to FairCMakeModules: FairRootGroup/FairCMakeModules#23

[ChristianTackeGSI]

Short Update:
FairCMakeModules 1.0.0 was just released.

It contains FairRootGroup/FairCMakeModules#23

Using this, we can now start to implement the requested feature.

[ChristianTackeGSI]

Just a status update:

TL;DR this has not been forgotten

I want to implement this using FairCMakeModules new fair_get_git_version(). This is included in FairCMakeModules 1.0.

But the CI images for FairRoot have not yet been updated. And we want to first get these updates more autoamted and robust.

[ChristianTackeGSI]

#1381 should add most of the stuff that was requested.