I'm having trouble with the changes from rev 5fa68c1 on a system running cmake 2.6-patch 4 (RHEL 6.4). A more recent cmake 2.8.11 works fine. The error message is:

CMake Error at cmake-modules/GetGitRevisionDescription.cmake:47 (get_filename_component):
  get_filename_component called with incorrect number of arguments

It would be nice to add this CMake module into the repository:

http://jesnault.fr/website/document-your-cmake-code-within-doxygen/

Hi,

The tag is not correctly propagated if the tag is in a detached mode.
This is basically the same issue as the issue below, but instead of a branch the information needed is a tag.
#3

You can recreate the issue by creating a tag on a different branch than master, for example, the branch should not be checkout, but you directly check out the tag.

Cheers
Alina

Description

Issue present in 77982ba

• 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

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.

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.

Hi,

Is there a way to run git_describe in every build and not just in generation time?
thanks,
Kobi

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.

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

If we directly invoke: git checkout HASH and if there is no named branch there then get_git_head_revision fails because .git/HEAD contains hash directly.

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.

if [ -f "${relative}" ]; then

Should probably read:

    # Look through nearly every file in the cmake-modules repo, but don't copy this file to your project!
    (cd $MODULES_DIR && git ls-files | grep -v "update-modules") | while read -r relative; do
        if [ -f "${MODULES_DIR}/${relative}" ]; then
            echo "${relative}"
            cp "${MODULES_DIR}/${relative}" .
        fi
    done

Currently only CXX is accepted:
https://github.com/rpavlik/cmake-modules/blob/master/CppcheckTargets.cmake#L186
https://github.com/rpavlik/cmake-modules/blob/master/CppcheckTargets.cmake#L82
However cppcheck will check both C and C++

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

I drafted up a little conan module to import the CMake scripts:

https://github.com/kheaactua/conan-cmake-modules

If your interested, I could create a pull request to add details into the README of how to include it, and also add a test_package to make it a proper conan recipe.

Saw this the other day, looks quite useful for finding C++ 11 support:

http://stackoverflow.com/a/13571695

Adding a new git tag does not force a re-configure if cmake variables with git_get_exact_tag

git_get_exact_tag(GIT_TAG)
if(NOT GIT_TAG)
    set(GIT_TAG "")
endif()
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/gitinfo.cpp.in ${CMAKE_CURRENT_BINARY_DIR}/gitinfo.cpp)

Some files:

gitinfo.h

extern const char g_GIT_TAG[];

gitinfo.cpp.in

#define GIT_TAG "@GIT_TAG@"
const char g_GIT_TAG[] = GIT_TAG;

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.

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

My project contains a source file detailing software version information, which I touch at the start of every build to ensure that it is unconditionally built such that a project build timestamp derived from C __DATE__ and __TIME__ macros is up to date.

The git diff-index --quiet HEAD -- command used in the git_local_changes() function results in the repo. being evaluated as dirty once a source file has been touched, and doesn't come right until some other git operation performs an index refresh.

See https://stackoverflow.com/questions/34807971 for a discussion of git diff-index behaviour.

Seems to me that using git diff --quiet HEAD -- instead results in desired behaviour. Alternately can issue git update-index --refresh before the git diff-index call.

I've been using your git revision description module. Works great!

If I understand this module correctly, it watches files in .git/ and then copies them to CMakeFiles/ which then triggers a rebuild.

Since it triggers a complete rebuild, I simply include the description variable as a preprocessor macro.

I'm wondering if there is a way to trigger a rebuild of only one file. Perhaps have a git_revision.cpp.in that looks like

#include "git_revision.hpp"

const static std::string git_revision = "@git_description@";

and git_revision.hpp

#ifndef GIT_REVISION_HPP
#define GIT_REVISION_HPP

const static std::string git_revision;

#endif

and only trigger a rebuild of git_revision.cpp when a committ, pull, etc. occurs.

Any ideas?

Here variable ${GIT_EXECUTABLE} is used, but find_package(Git QUIET) is not called beforehand, thus it's empty resulting in empty ${out} and so on.

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?

First, thanks a lot for sharing your cmake modules. Especially CreateLaunchers.cmake is really helpful.
But here comes the problem: Some of the dll's have the same name for debug and release builds, but are in different directories. So it would be really cool to be able to write this:

create_target_launcher(myprog
ARGS "/config Default_3D"
RUNTIME_LIBRARIES_Debug ${PL_RUNTIME_DIRS_DEBUG}
RUNTIME_LIBRARIES_Release ${PL_RUNTIME_DIRS_RELEASE}
RUNTIME_LIBRARIES_RelWithDebInfo ${PL_RUNTIME_DIRS_RELEASE}
RUNTIME_LIBRARIES_MinSizeRel ${PL_RUNTIME_DIRS_RELEASE}
WORKING_DIRECTORY ${PROJECT_MAIN_DIR}/App/bin
)

I'm not sure if it's easier to try to emulate it with the ENVIRONMENT option and the VS variable $(ConfigurationName), or if it's easier to modify the cmake code.
What do you think?

Current FindSDL2.cmake only supports to find SDL2 in MingW environment on Window. We can download and install sdl2 with command ./vcpkg install sdl2:x64-windows on Windows, and it's great if FindSDL2.cmake can support this situation.

I added to my own version support for MSVC11 compiler in CreateLaunchers.cmake:

    if(MSVC11)
        set(LAUNCHER_LINESEP "\n")
        set(USERFILE_VC_VERSION 11.00)
        set(USERFILE_EXTENSION user)
        set(VCPROJ_TYPE vcxproj)
    elseif(MSVC10)

I'm trying to build using OpenSceneGraph branch 3.6 that I built from their git repository, and the CMake module fails in the following way:

[ FindOpenSceneGraph.cmake:157 ] Failed to parse version number, please report this as a bug
-- Found osgDB: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosgDB.so  
-- Found osgViewer: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosgViewer.so  
-- Found osgText: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosgText.so  
-- Found osgGA: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosgGA.so  
-- Found osgParticle: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosgParticle.so  
-- Found osgUtil: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosgUtil.so  
-- Found osgFX: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosgFX.so  
-- Found osgShadow: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosgShadow.so  
-- Found osgAnimation: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosgAnimation.so  
-- Found osg: /home/dmbaturin/opt/openmw/osg-openmw/lib/libosg.so  
-- Found OpenThreads: /home/dmbaturin/opt/openmw/osg-openmw/lib/libOpenThreads.so  
CMake Error at /usr/share/cmake/Modules/FindOpenSceneGraph.cmake:226 (message):
  ERROR: Version 3.3.4 or higher of the OSG is required.  Version ..  was
  found.
Call Stack (most recent call first):
  CMakeLists.txt:358 (find_package)

I'm ready to do any additional testing if required.

The include/osg/Version file looks fine.

#ifndef OSG_VERSION
#define OSG_VERSION 1

#include <osg/Export>

extern "C" {

#define OPENSCENEGRAPH_MAJOR_VERSION    3
#define OPENSCENEGRAPH_MINOR_VERSION    6
#define OPENSCENEGRAPH_PATCH_VERSION    5
#define OPENSCENEGRAPH_SOVERSION        162

I am not a CMake expert; I'm far more accustomed to raw GNU Make. One of the idioms I usually bake into build systems is automatic version updating such that the version string is determined from git tags and updated on each commit. This works great for simplifying release workflows, and as long as everybody (including automated deployments, etc.) builds from git working trees it works great.

For more traditional software release paradigms where a source tarball is distributed, this is a little more complicated. Since people will not always be building from a git working tree but may be working from a source tarball, one has to include a fallback to determine the version number.

Using GNU Make based builds I know how to do this by bundling a version file with the latest string into the source, and falling back to reading it in the event git is not available. This way make dist or whatever will produce a tarball with an internal data file that can be read in lieu of git describe.

I am trying to contribute a similar workflow to a project that uses CMake. I've successfully included GetGitRevisionDescription from this repository and adapted the build to fetch the version string and define project() using it.

include(GetGitRevisionDescription)
git_describe(GIT_VERSION --tags --always)
string(REGEX REPLACE "-([0-9]*).*" ".\\1" VERSION "${GIT_VERSION}")
project (myproject
	VERSION "${VERSION}")

What I can't figure out is where and how I should cache this project data such that the project can also be build from source tarballs.

It would be nice to see the documentation comments for GetGitRevisionDescription include some notes on the best way to go about using it "offline".

Looks like it can't find correct folder, instead of trying to find .git by hand, maybe it's more wise to use git rev-parse --git-dir.

Otherwise you might get this output:
$ git describe
fatal: No tags can describe 'ffdc9780376f57d4cff1f07c835f7516c482d28d'.
Try --always, or create some tags.