git_describe_working_tree dirty/clean detection unreliable

[bmcdonnell-fb]

cmake-modules/GetGitRevisionDescription.cmake

Lines 3 to 4 in 1b45049

	# These functions force a re-configure on each git commit so that you can
	# trust the values of the variables in your build system.

Where/how is that implemented?

It is insufficient to cause the git_describe_working_tree function to reliably generate (or not generate) the -dirty suffix. Ideally, it should also force a reconfigure when the git working tree status toggles between dirty/clean. (Or when such status has changed since the last cmake configure.)

To observe:

1. Setup
   • Set up a project with a target that captures the output of git_describe_working_tree
   • git commit
   • CMake configure & build. Note the captured version is clean (no -dirty suffix)
2. False clean detection
   • Modify a tracked source file. Git worktree status is now dirty.
   • Build the project
     • CMake does not automatically (re)configure
     • Captured version is missing the -dirty suffix
3. False dirty detection
   • CMake configure (manually) & build
     • Captured version now correctly contains the -dirty suffix
   • git reset --hard. Build again
     • Captured version still (errantly) contains the -dirty suffix

@rpavlik, @dawid-aurobit (contributor of #41)

[bmcdonnell-fb]

Related:

• CMake #20892 - CMAKE_CONFIGURE_DEPENDS-like option for external commands
• CMake #21061 - add_custom_command() inconsistent behaviour when an OUTPUT doesn't get created (Makefiles generator)

[bmcdonnell]

cmake-modules/GetGitRevisionDescription.cmake

Lines 3 to 4 in 1b45049

	# These functions force a re-configure on each git commit so that you can
	# trust the values of the variables in your build system.

Where/how is that implemented?

It seems that the quoted comment is not true. I CMake configure and build my project, then make a small change to a source file, commit it, and build again. It does not trigger a new CMake configure.