Write the version number in one place and print the commit with --version

[aoymt]

Summary

The version number was written by hand in six files, and tenes --version printed the same 2.2-dev for every build of develop and of any feature branch.

This PR makes set(TENES_VERSION ...) in the top-level CMakeLists.txt the only place where the number is written, and makes --version print the commit the program was built from.

$ tenes --version
TeNeS v2.2-dev (3386c1cd)
$ tenes_std --version
2.2-dev (3386c1cd)
$ tenes_simple --version
2.2-dev (3386c1cd)

Changes

• --version of tenes, tenes_simple and tenes_std prints the version number followed by the first 8 digits of the commit hash, and -dirty when the source tree had uncommitted changes to tracked files.
• output/timers.json records the commit in meta as git_commit (the full hash) and git_dirty. Both are null when the commit is not known.
• The manual shows the version number alone. conf.py reads it from CMakeLists.txt.
• One place for the number. src/version.hpp, the two Python tools and the two conf.py no longer carry a copy.

Where the commit comes from

Source tree	Commit
git checkout	asked from git at every build
tarball made by git archive (the source archives of GitHub)	read from config/git_archive.txt, filled in through export-subst
any other copy of the sources	not known; the version number is printed alone

Notes on the choices:

• The commit is looked up at build time, not at configuration, because a new commit does not trigger a new configuration. version.cpp and the built tools are rewritten only when their content changes, so a build with nothing new compiles and links nothing.
• The embedded value is %H, not %(describe). The tags of this repository are lightweight, and the hash does not depend on the version of git.
• When git cannot read the checkout (for example under sudo make install, where git refuses the repository of another user), the values of the last build are kept.
• A Python tool run from the source tree, without CMake, looks up the number and the commit when --version is asked for. A tool copied out of the tree prints unknown rather than the commit of whatever repository it landed in.

Compatibility

• TENES_VERSION in version.hpp is still a macro, but it now expands to a function call, tenes::version(), and is no longer a string literal. Code that concatenates it as a literal ("v" TENES_VERSION) has to be changed. version.hpp is an installed header.
• timers_to_json() takes two more arguments (git_commit, git_dirty).
• The values live in a generated version.cpp; version.hpp only declares them. A generated header would lose against a stale src/version.hpp in #include "version.hpp", and would drop out of the installed headers.

Also fixed

The shebang of the built tools is now written by the same CMake script. The default interpreter, /usr/bin/env python3, is a list of two elements for CMake and is joined before it is passed on.

Release procedure

Tags are created at release time and are kept equal to TENES_VERSION by hand. No check in CI is added.

Tests

• ctest: 77/77 (Apple clang, no MPI, Release).
• New: test/python/test_version.py (18 cases), and two cases in test/timer_registry.cpp.
• tenes, tenes_std and tenes_simple print the same commit when built from a git checkout and from a git archive tarball. This was checked before the rebase onto the current develop; the build from a checkout was checked again after it.
• The English manual builds with Sphinx and shows TeNeS 2.2-dev documentation (checked before the rebase).

Not tested:

• an MPI build,
• the Ninja generator,
• a source archive downloaded from GitHub itself (checked with a local git archive).

Notes for reviewers

• The display is fixed at 8 digits, which is what git rev-parse --short prints in this repository.
• The source archives of GitHub do not contain the submodules (mptensor, toml11), so a tarball alone still cannot be built. This PR does not change that.

🤖 Generated with Claude Code

[yomichi]

Thanks. I checked that the hash comes out right from a checkout, a worktree and a git archive tarball, that -dirty follows tracked files only, and that a second build compiles and links nothing (Makefiles and Ninja). A few points:

1. No test fails when the commit is no longer embedded.
In a git checkout, the hash is optional everywhere it is checked:

• test/CMakeLists.txt: ( \([0-9a-f]+(-dirty)?\))? for version_*,
• test/timer_registry.cpp: the hash.empty() branch of "version_string is the version number followed by the commit",
• test/python/test_version.py: test_format and test_version_option.

With config/git_hash.cmake changed to always return an empty hash, tenes --version prints TeNeS v2.2-dev, and version_tenes, version_tenes_simple, version_tenes_std and test_timer_registry still pass. With the runtime lookup of the Python tools changed to return "", all 18 cases of test_version.py still pass. Could the tests require the hash when the source tree is a git checkout (for example, by choosing the regex at configure time from whether ${TeNeS_SOURCE_DIR}/.git exists)?

2. (Minor) When git cannot read the checkout, the whole output is kept.
config/write_version.cmake returns before it reads INPUT when TENES_GIT_FAILED is set and OUTPUT exists (lines 15-18). Since this script is also the only path from tool/tenes_std.py to build/tool/tenes_std, an edit to a tool or a new TENES_VERSION then silently does not reach the build. This needs a checkout that git cannot read at build time (e.g. built in a container as another user), so it is rare, but keeping only the hash and the dirty flag of the last build, and always filling in INPUT, would avoid it.

3. (Minor) sudo make install and git status.

• The comment in write_version.cmake and the description say that git refuses the repository under sudo make install. Current git allows it: under sudo, safe.directory accepts a repository owned by SUDO_UID (see git help config, written for "make && sudo make install"). So that case does not take the TENES_GIT_FAILED branch, and the comment could name another case.
• git status refreshes .git/index when the stat data is stale, so a build can take index.lock while the user runs git. git --no-optional-locks status (in config/git_hash.cmake and in the two tools) avoids this, and is what git recommends for tools that run in the background.

Not tested: an MPI build, CMake 3.8 itself.