feat: auto-generate version from git tags#11
Conversation
Replaces hardcoded VERSION 1.0.0 in CMakeLists.txt with git describe output. Adds version.hpp.in template that CMake configures at build time. Demo now prints version string on startup. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
/gemini review |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a great feature to automatically generate the project version from git tags. The overall approach is sound. I've provided a couple of suggestions for the CMakeLists.txt file to improve the robustness of the implementation. Specifically, I recommend using find_package(Git) for more reliable git command execution and adjusting the version parsing regex to handle common tag formats. The other changes look good.
CMakeLists.txt
Outdated
| set(SR_VERSION "0.0.0-unknown") | ||
| endif() | ||
|
|
||
| string(REGEX MATCH "^([0-9]+)\\.([0-9]+)\\.([0-9]+)" _ver_match "${SR_VERSION}") |
There was a problem hiding this comment.
The current regex will fail to parse git tags that have a v prefix (e.g., v1.2.3), which is a common convention. To make the version parsing more robust, the regex should be updated to optionally match the v prefix.
string(REGEX MATCH "^v?([0-9]+)\\.([0-9]+)\\.([0-9]+)" _ver_match "${SR_VERSION}")
CMakeLists.txt
Outdated
| execute_process( | ||
| COMMAND git describe --tags --always | ||
| WORKING_DIRECTORY ${CMAKE_SOURCE_DIR} | ||
| OUTPUT_VARIABLE SR_VERSION | ||
| OUTPUT_STRIP_TRAILING_WHITESPACE | ||
| ERROR_QUIET | ||
| ) | ||
| if(NOT SR_VERSION) | ||
| set(SR_VERSION "0.0.0-unknown") | ||
| endif() |
There was a problem hiding this comment.
For better robustness, it's recommended to use find_package(Git) to locate the git executable and ensure the project is within a Git repository before attempting to run git commands. This avoids potential errors or unexpected behavior when building from a source distribution that doesn't include the .git directory or on systems where git is not in the default PATH.
find_package(Git QUIET)
if(GIT_FOUND AND EXISTS "${CMAKE_SOURCE_DIR}/.git")
execute_process(
COMMAND ${GIT_EXECUTABLE} describe --tags --always
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
OUTPUT_VARIABLE SR_VERSION
OUTPUT_STRIP_TRAILING_WHITESPACE
ERROR_QUIET
)
endif()
if(NOT SR_VERSION)
set(SR_VERSION "0.0.0-unknown")
endif()
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces an automated versioning system for the soft_render project. By leveraging Git tags, the build process now dynamically determines and embeds the project's version, eliminating the need for manual updates. This enhancement streamlines release management and ensures that compiled binaries accurately reflect their source control state. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
Use find_package(Git) with .git dir check for robustness in non-git builds. Handle v-prefixed tags (e.g. v1.2.3) in version regex. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a great feature to automatically generate the version number from git tags. The implementation is clean and follows a common pattern for CMake projects. I've made one suggestion in CMakeLists.txt to improve the robustness of the git command execution by using find_package(Git). Otherwise, the changes look good and are well-implemented.
| find_package(Git QUIET) | ||
| if(GIT_FOUND AND EXISTS "${CMAKE_SOURCE_DIR}/.git") | ||
| execute_process( | ||
| COMMAND ${GIT_EXECUTABLE} describe --tags --always | ||
| WORKING_DIRECTORY ${CMAKE_SOURCE_DIR} | ||
| OUTPUT_VARIABLE SR_VERSION | ||
| OUTPUT_STRIP_TRAILING_WHITESPACE | ||
| ERROR_QUIET | ||
| ) | ||
| endif() |
There was a problem hiding this comment.
For better robustness and portability, it's good practice to use CMake's find_package to locate Git before attempting to execute it. This ensures that the build system doesn't fail unexpectedly in environments where git is not in the default PATH, and uses the executable found by CMake's search logic.
find_package(Git QUIET)
if(Git_FOUND)
execute_process(
COMMAND ${GIT_EXECUTABLE} describe --tags --always
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
OUTPUT_VARIABLE SR_VERSION
OUTPUT_STRIP_TRAILING_WHITESPACE
ERROR_QUIET
)
endif()
if(NOT SR_VERSION)
set(SR_VERSION "0.0.0-unknown")
endif()
There was a problem hiding this comment.
Code Review
This pull request effectively implements automatic version generation from Git tags, significantly improving upon hardcoded versions. The security review found no vulnerabilities. The approach using git describe and configure_file is appropriate, and the fallback to "0.0.0-unknown" along with the parsing of version components is well-considered.
| string(REGEX MATCH "^v?([0-9]+)\\.([0-9]+)\\.([0-9]+)" _ver_match "${SR_VERSION}") | ||
| if(_ver_match) | ||
| set(SR_VERSION_MAJOR ${CMAKE_MATCH_1}) | ||
| set(SR_VERSION_MINOR ${CMAKE_MATCH_2}) | ||
| set(SR_VERSION_PATCH ${CMAKE_MATCH_3}) | ||
| else() | ||
| set(SR_VERSION_MAJOR 0) | ||
| set(SR_VERSION_MINOR 0) | ||
| set(SR_VERSION_PATCH 0) | ||
| endif() |
There was a problem hiding this comment.
The current regex for parsing major, minor, and patch versions (^v?([0-9]+)\.([0-9]+)\.([0-9]+)) strictly requires all three components (major.minor.patch). If a Git tag is in a format like v1.0 or 1.0 (missing the patch component), the regex will not match, causing the major, minor, and patch versions to incorrectly default to 0 instead of 1, 0, 0. This can lead to misleading version information in the generated header. Consider making the minor and patch components optional in the regex to handle such cases more robustly.
string(REGEX MATCH "^v?([0-9]+)\\.?([0-9]*)\\.?([0-9]*)" _ver_match "${SR_VERSION}")
if(_ver_match)
set(SR_VERSION_MAJOR ${CMAKE_MATCH_1})
if(CMAKE_MATCH_2)
set(SR_VERSION_MINOR ${CMAKE_MATCH_2})
else()
set(SR_VERSION_MINOR 0)
endif()
if(CMAKE_MATCH_3)
set(SR_VERSION_PATCH ${CMAKE_MATCH_3})
else()
set(SR_VERSION_PATCH 0)
endif()
else()
set(SR_VERSION_MAJOR 0)
set(SR_VERSION_MINOR 0)
set(SR_VERSION_PATCH 0)
endif()
1 participant
Summary
VERSION 1.0.0in CMakeLists.txt withgit describe --tags --alwaysversion.hpp.intemplate configured at build time intobuild/generated/soft_render 0.0.2-17-g9f8a5e9)How it works
Tag a release (
git tag 0.1.0) and the next build picks it up automatically. Between tags, the fullgit describeoutput (tag + commit count + hash) is used.Test plan
cmake -B build && cmake --build build)🤖 Generated with Claude Code