[CMake] Putting the git commit hash in a cmake variable

[Ryan Pavlik]

Fwiw, this is my single most popular stack overflow post (and presumably my
most popular CMake module)
https://stackoverflow.com/questions/1435953/how-can-i-pass-git-sha1-to-compiler-as-definition-using-cmake/4318642#4318642

It does incorporate the other ideas that have come up, like making a
dependency on a git data file.

Ryan

On Fri, Oct 12, 2018, 10:33 AM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> Sorry if this shows up oddly on the list; I was forwarded the original
> in order to reply. As such, please keep me in Cc.
>
> > I'd like to set a CMake variable to the current git commit short hash.
> > This variable will be used as part of the version string for my
> > project (ex: "1.0.1+git.${SHORT_HASH}"). I can get at this short hash
> > by using execute_process and setting the resulting output to a
> > variable.
> >
> > ```cmake
> > execute_process(
> >     COMMAND
> >         git rev-parse --short HEAD
> >     RESULT_VARIABLE
> >         SHORT_HASH_RESULT
> >     OUTPUT_VARIABLE
> >         SHORT_HASH)
> > ```
> >
> > My issue is that cmake will only run execute_process once, during the
> > configure step. I need cmake to run this execute_process on every
> > build and, if the output has changed, reconfigure to make sure
> > SHORT_HASH is up to date.
> >
> > I came up with one solution to this issue: During the configure step,
> > I can write the current short hash to a file named short_hash.txt. On
> > every build, I'll re-compute the short hash and verify that the
> > computed short hash is the same as what is in short_hash.txt. If its
> > not, I'll write the new short hash to short_hash.txt. I then make
> > short_hash.txt an input to configure_file. This will cause cmake to
> > validate SHORT_HASH is properly set, and re-configure if its not.
>
> I solved this a few years ago :) . Here are all the relevant files:
>
>
> https://github.com/Kitware/sprokit/blob/master/src/sprokit/version.h.in
>
> https://github.com/Kitware/sprokit/blob/master/src/sprokit/.gitattributes
>
> https://github.com/Kitware/sprokit/blob/master/src/sprokit/CMakeLists.txt
>
> https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake
>
> Basically the solution follows:
>
>   - If we're in an archive (.gitattributes' export-subst), use the
>     information from it. Detect this in CMake by checking if Git
>     replaced substitutions for us:
>
>         if ("$Format:$" STREQUAL "")
>
>     If we are, just use that information (gathered using other
>     `$Format:$` expansions).
>   - If not, we set up some code to run at build time to extract the
>     information.
>   - The variables (or code) from above is injected via
>     `sprokit_configure_file_always` which basically is just a
>     `configure_file` done at build time. The list of variables to export
>     to the script are listed as arguments. The `_always` bit just adds
>     an extra output file named `${output}.noexist` which causes tools to
>     always run the associated custom command (which is then attached to
>     a custom target via its output file).
>
> The file is only updated if the contents change (via `configure_file`),
> so rebuilding should be minimal.
>
> --Ben
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20181014/25f0d1b0/attachment.html>