-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
full cmake 1/N: git and ref in configuration.cc #299
Conversation
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?
Scans good.
For pre-releases |
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 |
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.
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 |
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. |
+ reformat tests/unit/test.cc
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