[cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cmake at cmake.org

[Ben Boeckel]

On Mon, Oct 05, 2015 at 12:50:41 +0200, Daniel Wirtz wrote:
> thanks for the feedback, i've included most of it.
> 
> Regarding the configure/build issue: that indeed is inconvenient and may 
> cause irritation. on the other side, if there has been git activity 
> fussing with any source files affecting the build, cmake will run again 
> and hence capture the possibly new git info. so the case where you 
> change the revision after configure to an extent where cmake will not 
> automatically re-run is uncommon, at least for my guessing.
> however, i've included an explicit warning in the docs to raise awareness.

Well, without depending on every file in the source tree, it will just
be wrong rather than causing excess configure runs. Adding something
like "configure this file at build time" setup would need to be the
basis though (basically porting and cleaning up sprokit_configure_file()
into CMake as deferred_configure_file() or something similar would work).

> i'm happy to provide a suitable procedure that is flexible enough; 
> providing scripts that configure files (like with sprokit) seems too 
> specific as people might want to have a single "config.h" file or so 
> containing more than just the git info.

The sprokit mechanism configures any file using code to determine some
of the variables at build time. It is by no means limited to just header
files. The code injection is a little clunky (being a string and all),
but it could also be changed to an include() statement with an extra
depends on that included file. In fact, with include(), adding support
for SVN, Mercurial and others would be pretty simple as well rather than
duplicating all this for each revision system.

> i've thought about the possibility to generate an explicit 
> "git_version.h" file to include, but that 1) restricts possible 
> languages and 2) will require an extra build target that is run each 
> build etc. any thoughts?

Well, you will indeed never have a "nothing to do" build with such a
target, but such information is effectively derived from "this depends
on every file in the tree tracked by git as well as the .git/HEAD,
.git/index, and .git/refs/tags/* files" so "always something to do"
isn't that far off. The step (in sprokit) takes ~0 time to run
anyways[1], so speed isn't an issue.

--Ben

[1]45 build trees took < 2 seconds, so figuring for some overhead for
exec() of ninja itself and ninja scanning, the overhead for checking the
git revision is < .05s for a smallish source tree. Something like
webkit's git mirror could take a while though.