Previously, the version string would include `v2022.4-N-...` indicating N commits since the last annotated tag (`v2022.4`).
This change broadens the search from just annotated tags to all tags that match `v*`, including the latest version `v2023.4.rc2`.
See also: https://github.com/KhronosGroup/SPIRV-Tools/pull/5417#issuecomment-1764772856
When building, .git directory may not exist in current
directory (e.g. chromium build), so it will produce
with current timestamp, which becomes non-deterministic build.
Check if repo_path is in git repository and use git info.
Also fix fallback logic when 'git describe' failed.
'git rev-parse HEAD' result was not used because it didn't
update success.
When we are attempting to fetch the version info from the git
repository, first check if we're actually in one, otherwise
spurious errors messages get printed.
In a Chromium build environment on Windows git is supplied by
depot_tools as git.bat. This was causing build errors on Windows that
are most easily reproduced with this command:
gn gen out\default && gn clean out\default && ninja -C out\default spirv-as
The errors included:
[12:55:40][ERROR ] Failed to run "['git', 'tag', '--sort=-v:refname']" in "C:\src\chromium\src\third_party\vulkan-deps\spirv-tools\src": [WinError 2] The system cannot find the file specified
[12:55:40][WARNING ] Could not deduce latest release version from history.
This is because 'git' does not resolve to git.bat unless shell=True is
passed to subprocess.Popen. This change passes shell=True but only on
Windows which resolves these errors.
When the build is done on a shallow repo, or on a non-git copy,
the version script failed. We should not hard fail, but generate
a "version" (unknown).
Sample outputs:
with git history:
`"v2023.2-dev", "SPIRV-Tools v2023.2-dev v2022.4-87-g53541064"`
with shallow clone:
`"unknown_version", "SPIRV-Tools unknown_version d8759a140bc65811332d5f91f3b08febadd5a21d"`
not a git repo:
`"unknown_version", "SPIRV-Tools unknown_version unknown_hash, 2023-02-02T16:25:48.077995"`
The CHANGES file was an alternative source of truth that was trying
to duplicate/replace the git history truth.
This allow us to change the way we handle releases so we don't have to make
sure our CHANGES PR are linked to the tag and tested PR, simplifying the
process.
* Fix gen_build_version on Windows
The paths used in the gen_build_version script are causing some failures
in downstream builds. Switch to using the location of the CHANGES file
rather than the ".." parent directory workaround.
* Update other build files
- Parse CHANGES file with Universal Python line endings in case
the source tree was checked out with Windows line endings.
- Use our own clone of strnlen_s which might not be available
everywhere.
Fixes https://github.com/KhronosGroup/SPIRV-Tools/issues/508
Add a high level version number for SPIRV-Tools, beginning
with v2016.0-dev. The README describes the format of the
version number.
The high level version number is extracted from the CHANGES
file. That works around:
- stale-bait for when we don't add tags to the repository
- our inability to add tags to the repository
Option --version causes spirv-as, spirv-dis, and spirv-val to
show the high level version number.
Add spvSoftwareVersionString to return the C-string for
the high level version number.
Add spvSoftwareVersionDetailsString() so that clients can get
more information if they want to.
Also allows us to clean up the uses in the tool executables files,
so now only one file includes build-version.inc.
Move the update-build-version logic to the only
CMakeLists file that needs it.
The update build version script takes a new argument
to name the output file.
When the given directory is not inside the SPIRV-Tools project,
describe() returns a str instance instead of bytes instance
in Python3, which will case problem when calling decode() on it.
