Fwiw, this is my single most popular stack overflow post (and presumably my most popular CMake module) <a href="https://stackoverflow.com/questions/1435953/how-can-i-pass-git-sha1-to-compiler-as-definition-using-cmake/4318642#4318642">https://stackoverflow.com/questions/1435953/how-can-i-pass-git-sha1-to-compiler-as-definition-using-cmake/4318642#4318642</a><div><br></div><div>It does incorporate the other ideas that have come up, like making a dependency on a git data file.</div><div><br></div><div>Ryan<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 12, 2018, 10:33 AM Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry if this shows up oddly on the list; I was forwarded the original<br>
in order to reply. As such, please keep me in Cc.<br>
<br>
> I'd like to set a CMake variable to the current git commit short hash.<br>
> This variable will be used as part of the version string for my<br>
> project (ex: "1.0.1+git.${SHORT_HASH}"). I can get at this short hash<br>
> by using execute_process and setting the resulting output to a<br>
> variable.<br>
> <br>
> ```cmake<br>
> execute_process(<br>
> COMMAND<br>
> git rev-parse --short HEAD<br>
> RESULT_VARIABLE<br>
> SHORT_HASH_RESULT<br>
> OUTPUT_VARIABLE<br>
> SHORT_HASH)<br>
> ```<br>
> <br>
> My issue is that cmake will only run execute_process once, during the<br>
> configure step. I need cmake to run this execute_process on every<br>
> build and, if the output has changed, reconfigure to make sure<br>
> SHORT_HASH is up to date.<br>
> <br>
> I came up with one solution to this issue: During the configure step,<br>
> I can write the current short hash to a file named short_hash.txt. On<br>
> every build, I'll re-compute the short hash and verify that the<br>
> computed short hash is the same as what is in short_hash.txt. If its<br>
> not, I'll write the new short hash to short_hash.txt. I then make<br>
> short_hash.txt an input to configure_file. This will cause cmake to<br>
> validate SHORT_HASH is properly set, and re-configure if its not.<br>
<br>
I solved this a few years ago :) . Here are all the relevant files:<br>
<br>
<a href="https://github.com/Kitware/sprokit/blob/master/src/sprokit/version.h.in" rel="noreferrer" target="_blank">https://github.com/Kitware/sprokit/blob/master/src/sprokit/version.h.in</a><br>
<a href="https://github.com/Kitware/sprokit/blob/master/src/sprokit/.gitattributes" rel="noreferrer" target="_blank">https://github.com/Kitware/sprokit/blob/master/src/sprokit/.gitattributes</a><br>
<a href="https://github.com/Kitware/sprokit/blob/master/src/sprokit/CMakeLists.txt" rel="noreferrer" target="_blank">https://github.com/Kitware/sprokit/blob/master/src/sprokit/CMakeLists.txt</a><br>
<a href="https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake" rel="noreferrer" target="_blank">https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake</a><br>
<br>
Basically the solution follows:<br>
<br>
- If we're in an archive (.gitattributes' export-subst), use the<br>
information from it. Detect this in CMake by checking if Git<br>
replaced substitutions for us:<br>
<br>
if ("$Format:$" STREQUAL "")<br>
<br>
If we are, just use that information (gathered using other<br>
`$Format:$` expansions).<br>
- If not, we set up some code to run at build time to extract the<br>
information.<br>
- The variables (or code) from above is injected via<br>
`sprokit_configure_file_always` which basically is just a<br>
`configure_file` done at build time. The list of variables to export<br>
to the script are listed as arguments. The `_always` bit just adds<br>
an extra output file named `${output}.noexist` which causes tools to<br>
always run the associated custom command (which is then attached to<br>
a custom target via its output file).<br>
<br>
The file is only updated if the contents change (via `configure_file`),<br>
so rebuilding should be minimal.<br>
<br>
--Ben<br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div></div>