full cmake 1/N: git and ref in configuration.cc

[loriab]

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.

• 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?
• 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
• 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 and BUILD_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

-- LibintRepository_VERSION  2.8.0
-- LibintRepository_COMMIT   22fa24165540520e05ddc3ab3529498f14bc2061
-- LibintRepository_DISTANCE 0
-- LibintRepository_DESCRIBE v2.8.0
-- LIBINT_GIT_COMMIT         22fa241
-- Version: Full 2.8.0 Numeric 2.8.0 Sortable 2.8.0
-- SO Version: Full 2:3:0 Major 2

configuration.cc on-tag

const char *configuration_accessor(void) {
  // return "";
  return "(nyi)";
}

void libint_version(int *major, int *minor, int *micro) {
  *major = -1;
  *minor = -1;
  *micro = -1;
  sscanf(libint_version_string(ext = false), "%d.%d.%d", major, minor, micro);
}

const char *libint_version_string(bool ext) {
  if (ext)
    return "2.8.0";
  else
    return "2.8.0";
}

const char *libint_commit(void) { return "22fa241"; }

const char *libint_reference(void) {
  std::string ref;
  ref =
      "Libint: A library for the evaluation of molecular integrals of "
      "many-body operators over Gaussian functions, Version " +
      std::string(libint_version_string()) +
      " Edward F. Valeev, http://libint.valeyev.net/";
  return ref.c_str();
}

const char *libint_reference_doi(void) {
  return "10.5281/zenodo.10369117";  // 2.8.0
}

const char *libint_bibtex(void) {
  return "@Misc{Libint2,\n  author = {E.~F.~Valeev},\n  title = "
         "{\\textsc{Libint}: A library for the evaluation of molecular "
         "integrals of many-body operators over Gaussian functions},\n  "
         "howpublished = {http://libint.valeyev.net/},\n  note = {version "
         "},\n  year = {2023}\n}\n";
}

CMake configure off-tag

-- LibintRepository_VERSION  2.8.0
-- LibintRepository_COMMIT   434ce28320a2643d5c286446748735c14f9b736c
-- LibintRepository_DISTANCE 1
-- LibintRepository_DESCRIBE v2.8.0-1-g434ce28
-- LIBINT_GIT_COMMIT         434ce28
-- LIBINT_VERSION_YEAR       2023
-- Version: Full 2.8.0-post999 Numeric 2.8.0 Sortable 2.8.0.post1
-- SO Version: Full 2:3:0 Major 2

configutation .cc off-tag

const char *configuration_accessor(void) {
  // return "";
  return "(nyi)";
}

void libint_version(int *major, int *minor, int *micro) {
  *major = -1;
  *minor = -1;
  *micro = -1;
  sscanf(libint_version_string(ext = false), "%d.%d.%d", major, minor, micro);
}

const char *libint_version_string(bool ext) {
  if (ext)
    return "2.8.0.post1";
  else
    return "2.8.0";
}

const char *libint_commit(void) { return "434ce28"; }

const char *libint_reference(void) {
  std::string ref;
  ref =
      "Libint: A library for the evaluation of molecular integrals of "
      "many-body operators over Gaussian functions, Version " +
      std::string(libint_version_string()) +
      " Edward F. Valeev, http://libint.valeyev.net/";
  return ref.c_str();
}

const char *libint_reference_doi(void) {
  return "10.5281/zenodo.10369117";  // 2.8.0
}

const char *libint_bibtex(void) {
  return "@Misc{Libint2,\n  author = {E.~F.~Valeev},\n  title = "
         "{\\textsc{Libint}: A library for the evaluation of molecular "
         "integrals of many-body operators over Gaussian functions},\n  "
         "howpublished = {http://libint.valeyev.net/},\n  note = {version "
         "},\n  year = {2023}\n}\n";
}

[evaleev]

• 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?

• 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.

• 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 and BUILD_ID could possibly retire.

For pre-releases BUILD_ID might be useful. We'll deal with that when we get there.

[evaleev]

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?

[LecrisUT]

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.

[loriab]

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.