Closed loriab closed 1 month ago
- [x] Here's a project that connects git and CMake (w/o the extra python dep that psi4's equivalent requires). It would require CMake 3.19 (generator/compiler only not library). That would be ok with Ubuntu 22.04 which has 3.22 (EDIT: and I hear RHEL LTS is 3.20). I've copied over the relevant file,
DynamicVersion.cmake
into this PR. Do you think it's worth it?
Worth it. We've been ad libbing this for years: https://github.com/ValeevGroup/kit-cmake/blob/master/modules/GetGitMetadata.cmake ... would be great to use something more fully featured. Do you know if there there plans to PR this (or equivalent) into CMake itself?
- [x] New version and literature reference accessors are added to
configuration.h/cc
. Several are modeled on Libxc https://gitlab.com/libxc/libxc/-/blob/master/src/version.c
Scans good.
- [x] commit and a basic sortable version are accessible,
{Major}.{minor}.{patch}.post{distance}
, where distance is number of commits from any (annotated or lightweight) tag. Between these two, exports should be more addressable andBUILD_ID
could possibly retire.
For pre-releases BUILD_ID
might be useful. We'll deal with that when we get there.
one more piece of context: for assembling large projects with dependency graphs of 20+ subprojects (e.g. https://github.com/ValeevGroup/mpqc4/issues/426 ) would be convenient to use DynamicProject()
-like functionality from main project to harvest the info for each graph node ... it looks like DynamicProject()
is meant only to run from the top project?
Do you know if there there plans to PR this (or equivalent) into CMake itself?
Nothing specific that I know of, but if we can figure a good interface for this, I can submit a PR to package it in CMake itself. But before that I would want it to be tested by a few projects first.
it looks like
DynamicProject()
is meant only to run from the top project?
Currently it should be able to run for multiple projects, but I haven't actually tested it yet. After coming back to this, my only concern is PROJECT_SOURCE
. My plan is to be consumable by all projects via CMAKE_PROJECT_INCLUDE_BEFORE
so that all projects will have their version injected and you don't even have to call DynamicProject()
, just setup appropriate interface variables.
I'm not promoting a merge (esp. while v2.8.x is brewing), but converting this from draft to regular PR since there's no blockers to merging.
The steps to full cmake replacing #259 aren't going to be nicely separable, so I don't expect this to run on GHA. (EDIT: immediate error is an errant std::string that I'll fix up.) The best I can do is collect changes by topic, so here's the first one focusing on versioning and extra stuff for the configuration.cc file you mentioned in September.
DynamicVersion.cmake
into this PR. Do you think it's worth it?configuration.h/cc
. Several are modeled on Libxc https://gitlab.com/libxc/libxc/-/blob/master/src/version.c{Major}.{minor}.{patch}.post{distance}
, where distance is number of commits from any (annotated or lightweight) tag. Between these two, exports should be more addressable andBUILD_ID
could possibly retire.Overall, is this a satisfactory approach? And are there any other items you want accessible in configuration.cc?
Here's a few outputs for orientation:
CMake configure on-tag
configuration.cc on-tag
CMake configure off-tag
configutation .cc off-tag