There's a patch here. They mentioned upstreaming it but never got around to it.

To summarize, if you are versioning your home directory with git and unpack a source tarball then the CMake module will still traverse upwards and use the revision of the home directory. Most projects use a CMakeLists.txt in the root directory, so the traversal is not needed, and disabling it solves the issue.

It seems that git_describe() can't be used with --dirty - it will always return -128-NOTFOUND. When running the same command from the command line yields this:

$git describe HEAD --dirty
fatal: --dirty is incompatible with commit-ishes

So basically git doesn't like that we're passing both hash and --dirty. I don't see why we have to pass commit hash to git describe in git_describe(), by default git will just assume HEAD.

Description

Issue present in https://github.com/rpavlik/cmake-modules/commit/77982ba193e2baeffae13876fd4b0b77cff5576c

• cmake version 3.22.2
• Linux (Arch Distro)
• MakeFile Generator

We're using get_git_head_revision in the following way:

# Include git hash in source
include(CMakeModules/GetGitRevisionDescription.cmake)
get_git_head_revision(GIT_REFSPEC GIT_SHA1)
message(STATUS "Building ${CMAKE_PROJECT_NAME} GIT SHA1: ${GIT_SHA1}")

set_property(
  SOURCE ${CMAKE_CURRENT_LIST_DIR}/GitSHA1.cpp
  PROPERTY COMPILE_DEFINITIONS
    "GIT_SHA1=\"${GIT_SHA1}\""
)

It seems like for every different commit, instead of only recompiling changes + GitSHA1.cpp, our entire project is recompiled.

This makes it very annoying when doing things such as git bisect or rebases, or simply making new commits. It also wastes a lot of cycles.

How to reproduce

1. Any project making use of get_git_head_revision in a way similar to the above snippet
2. Compile the project once
3. Compile it again: there should be nothing new to compile
4. git commit --allow-empy -m "New SHA, no changes"

Current behaviour

Project reconfigures and will recompile every source file in project

Expected behaviour

Compiling the project once more should be like 3. above, except for only the files related to the SHA define recompiling

After recently upgrading to cmake 2.8.12 I get lots of warnings like this:

1> CMake Warning (dev) at App/cmake/CreateLaunchers.cmake:204 (get_target_property): 1> Policy CMP0026 is not set: Disallow use of the LOCATION target property. 1> Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy 1> command to set the policy and suppress this warning. 1>
1> The LOCATION property should not be read from target "CppExtTest". Use the 1> target name directly with add_custom_command, or use the generator 1> expression $<TARGET_FILE>, as appropriate. 1>
1> Call Stack (most recent call first): 1> App/cmake/CreateLaunchers.cmake:281 (_launcher_produce_vcproj_user) 1> App/CMakeLists.txt:264 (create_target_launcher) 1> App/CppExt/UnitTests/CMakeLists.txt:32 (PL_ADD_UNIT_TEST) 1> This warning is for project developers. Use -Wno-dev to suppress it.

And here is the long description:

cmake --help-policy CMP0026

CMP0026

Disallow use of the LOCATION target property.

CMake 2.8.12 and lower allowed reading the LOCATION target property to determine the eventual location of build targets. This relies on the assumption that all necessary information is available at configure-time to determine the final location and filename of the target. However, this property is not fully determined until later at generate-time. At generate time, the $<TARGET_FILE> generator expression can be used to determine the eventual LOCATION of a target output.

Code which reads the LOCATION target property can be ported to use the $<TARGET_FILE> generator expression together with the file(GENERATE) subcommand to generate a file containing the target location.

The OLD behavior for this policy is to allow reading the LOCATION property from build-targets. The NEW behavior for this policy is to not to allow reading the LOCATION property from build-targets.

This policy was introduced in CMake version 3.0.0. CMake version 2.8.12.20140106-gff6f80 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.

• OSG_ROOT and OSGHOME should be equivalent, the former appears appears to be the (new?) standard:
  • http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio
  • http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/CMakeModules/FindOSG.cmake
• But yet, OSGHOME still seems to be widely used:
  • OpenSceneGraph Tutorial Michael Kriegel, Meiyii Lim, Matthias Keysermann Heriot-Watt University, Edinburgh February 2011

Hi,

I'm using your cmake-modules to apply cppcheck to our sources (thanks!), however I found a small issue when using cppcheck version 1.5.3.

In cppcheck version 1.5.3, the unused functions test is enabled with: --enable=unusedFunction, however in your Findcppcheck.cmake module you have this as: --enable=unusedFunctions (note the additional 's').

I'm not sure what the earlier behaviour was but the current version does not work. Since this is a trivial fix I haven't created a pull request, but I'll try putting a diff in an additional comment.

Thanks, Brett

This uses generator expression to get rid of the cmake warnings with using the LOCATION property of the target. Also since generator expressions are being decoded in the file(GENERATE ...) call you can feed CreateLauncher generator expressions.

cc @russell-taylor who knows more about the circumstances since it's his machine.

Bug is presumably in https://github.com/rpavlik/cmake-modules/blob/master/FindMarkdown.cmake - perhaps there are specific executables to exclude, or a test we can do to determine if a given executable actually is a markdown parser at config time before we try to use it.

Here was the error message he got:

2>  Converting Markdown CONTRIBUTING.md to HTML in C:/tmp/vs2013_64/OSVR-Core/CONTRIBUTING.html...
2>  Access is denied.
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5): error MSB6006: "cmd.exe" exited with code 5.

Russ, what's the value of MARKDOWN_EXECUTABLE in that config?

This module found at https://github.com/kmorel/UseLATEX.

This module allows you to compile LaTeX files into PDF, PostScript files, etc... See http://www.cmake.org/Wiki/CMakeUserUseLATEX for further informations.

Hi @rpavlik

Would you be interested in adding FindNSS and FindNSPR to your repo?

This repo helps loads, and it would be great to add scripts we have separately to it - they are both BSD-Clause-3 licensed, originally by Andreas Schneider at RedHat.

Hi,

There are 2 issues with GetGitRevisionDescription.cmake.in

1. If only the logs folder exists than the hash = reference.
2. gc and prune delete refs folder and logs/refs and the script is crashing.

Cheers Alina

Fix inverted logic when checking if we are in a Git submodule. If we are in a submodule, out will be empty (as the comment correctly states). Therefore, we need to enter this block of code if out is empty, rather than not empty.

Hi: For now, GetGitRevision won't work as intended if current CMakeList directory is a symbolic link instead of a submodule.

I tried to apply a few patches and now it seems to work for me if I also pass ALLOW_LOOKING_ABOVE_CMAKE_SOURCE_DIR

I was seeing an error like this (anonymized):

CMake Error: File XXX/MyProject/SubmodulesInThisDir/.git/modules/SubmodulesInThisDir/Submodule/HEAD does not exist.
CMake Error at SubmodulesInThisDir/Submodule/cmake/GetGitRevisionDescription.cmake:161 (configure_file):
  configure_file Problem configuring file

Finally tracked it down to the fact that, for some reason, the get_git_head_revision() function of GetGitRevisionDescription does not include the

    if(NOT GIT_FOUND)
        find_package(Git QUIET)
    endif()

block that all the other public functions have. So, if this is the first GetGitRevisionDescription function you call, it takes the wrong code paths due to the inability to call Git and tries to configure the wrong file.

I often have small projects where I include big external libraries that are themselves git repositories in /opt. In those cases, it would be nice to 'read' the commit sha of those folders.

To achieve that, I guess that this line should take a variable argument, (with default value as now): https://github.com/rpavlik/cmake-modules/blob/main/GetGitRevisionDescription.cmake#L87