From 2034fe79dfaf7bb3cc9f5aa1cd6c56f46897fc96 Mon Sep 17 00:00:00 2001 From: David Seifert Date: Sat, 10 Aug 2019 22:21:39 +0200 Subject: Make `PROJECT_VERSION_GIT` fallback more robust * The previous check for `PROJECT_VERSION_GIT_RETURN_CODE` was fragile and did not check specifically that the return code is *exactly* 0. --- CMakeLists.txt | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 6d59430..1169e94 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -129,7 +129,14 @@ execute_process( ERROR_QUIET ) ENDIF() -IF((NOT ${ADD_GIT_INFO}) OR (${PROJECT_VERSION_GIT_RETURN_CODE})) +# the version.h generation logic is tricky in a number of ways: +# 1. git describe on a release tarball will always fail with +# a non-zero return code, usually 128 +# 2. If git is not installed, PROJECT_VERSION_GIT_RETURN_CODE +# will contain the string 'No such file or directory' +# Hence fallback to PROJECT_VERSION when the return code is NOT 0. +IF((NOT ${ADD_GIT_INFO}) OR (NOT ${PROJECT_VERSION_GIT_RETURN_CODE} STREQUAL "0")) + MESSAGE(STATUS "Setting fallback Git library version") SET(PROJECT_VERSION_GIT "v${PROJECT_VERSION}") ENDIF() MESSAGE(STATUS "Setting Git library version to: " ${PROJECT_VERSION_GIT} ) -- cgit v1.2.1