Add git-derived versioning and runtime-accessible version

[sethrj]

• Adds runtime-accessible ForTrilinos version (both integers and full descriptive string) to fulfill XSDK requirements
• Uses git release-derived metadata for generating this version and the embedded version info

[aprokop]

I feel like you chose a complicated approach. Why not do something like this?

Also, I don't think it catches the issue where you configured, but then switched branches. The code I linked does that. We were burned by that a lot.

[sethrj]

I'm using the same approach that I used in flibcpp; I didn't know about the ArborX one. The one I'm using is loosely derived from the python "versioneer" module, which has a few important features that ArborX lacks:

• It uses git describe information to derive the tagged release version; so the version will appear as v2.0.0 if we tag it as such, or v2.0.0+ab12 if it's a non-tagged version.
• It uses git archive to automatically embed the git data when downloading an automatically generated github .tar.gz version, so the version gets embedded even if it's not a git repository.
• It stores the result as CMake variables so that it can be used in the cmake project command to automatically set the version
• It generates major/minor/patch integers rather than just hash strings

ArborX's version detection is designed to update the version header at every compile, which (for larger projects) I've found to be more of a headache than a feature, because everything has to be recompiled or relinked. (In contrast, the cmake code I'm using caches the git-derived information to reduce reconfigure time.) I based the design of this cmake code on the idea that version numbering is more important for distribution than develop/build/test.

[aprokop]

ArborX's version detection is designed to update the version header at every compile, which (for larger projects) I've found to be more of a headache than a feature, because everything has to be recompiled or relinked. (In contrast, the cmake code I'm using caches the git-derived information to reduce reconfigure time.) I based the design of this cmake code on the idea that version numbering is more important for distribution than develop/build/test.

I agree with most of your point, and think it is a find approach. It depends on what you plan to do with a git version/hash, though. In ArborX, we run performance studies spitting out a log file with the hash. It is crucial that it is actually correct, especially when switching branches and comparing. In ForTrilinos context, it should be OK to do a configure only check. In short, you are right here, and I withdraw my comment.

[sethrj]

Excellent. There are definitely times where you do indeed want to be more aggressive about keeping the embedded git hash up to date -- if you're trying to do a git bisect to find a performance regression then the arborx way is definitely a good approach.