<div dir="ltr">I use essentially the technique in the answer below, except with `add_custom_target` instead of `add_custom_command`, so that the hash-generation is always run regardless of whether the temp file is successfully deleted:<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><a href="https://stackoverflow.com/a/41750028/508431">https://stackoverflow.com/a/41750028/508431</a><br></div><div><br></div></blockquote>I also use a dummy `add_custom_command` which depends on GITVER_FILE as in the above. IIRC the reason was that in my use case GITVER_FILE is passed as part of a sources list to a macro, and defining the custom command was the only way I could find to properly enforce an ordering dependency in parallel builds:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div># dummy output so we can depend on it in the external macro, because CMake.</div><div>add_custom_command(OUTPUT "${GITVER_FILE}"</div><div> DEPENDS _GEN_GITVER)</div></div><div><br></div></blockquote><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">(I think it was fine running `add_executable`/`add_library` directly in the current CMakeList, but ordering didn't work when passing to a macro -- at least in the version of cmake where I developed this)</span><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 23, 2018 at 2:50 PM Andrew Fuller <<a href="mailto:afuller@teradici.com">afuller@teradici.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div id="m_-4849961066468474242divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir="ltr">
Using configure_file() at CMake time will appear to work at first glance, but you'll wind up with stale information when you change revisions without any CMake change. CMake won't re-run automatically and thus your header file won't get updated. You'll need
to do it at build time to ensure it's always up-to-date.
<div><br>
</div>
<div>How do the translation units obtain the generated header? There needs to be some form of dependency between the generated header and the consumer(s). If you add the generated header as an input to another target, then CMake should ensure the file is
generated before processing the dependant target.</div>
<div><br>
</div>
<div>Also note that AFAICT add_custom_command will not re-run if the output file already exists (unless invalidated by a dependency). Since you're grabbing dynamic information like the commit hash, then you likely want it to run _every_ time. add_custom_target
might be better suited for your needs.</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-4849961066468474242divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> CMake <<a href="mailto:cmake-bounces@cmake.org" target="_blank">cmake-bounces@cmake.org</a>> on behalf of Robert Dailey <<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>><br>
<b>Sent:</b> July 19, 2018 8:05:06 AM<br>
<b>To:</b> CMake<br>
<b>Subject:</b> [CMake] Parallel builds and auto generated header files</font>
<div> </div>
</div>
<div class="m_-4849961066468474242BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="m_-4849961066468474242PlainText">I have a Version.hpp file that I have a custom command tied to which<br>
basically runs CMake in script mode to perform configure_file() on it<br>
during build time. The reason it does this is because it builds<br>
Version.hpp using dynamic information, such as defining a macro with<br>
the current SHA1 being built, etc.<br>
<br>
I notice in parallel builds, this header file gets built too late,<br>
because of parallel builds. What if a file includes the header and its<br>
translation unit is built before Version.hpp is generated by the<br>
custom command? Would it be better/simpler to do configure_file() at<br>
configuration time instead of at build time as a custom command?<br>
Here's the logic (some variables are defined elsewhere, but should<br>
give you the gist):<br>
<br>
<br>
set( generated_source_dir ${CMAKE_CURRENT_BINARY_DIR}/Source )<br>
set( version_file_in ${CMAKE_CURRENT_SOURCE_DIR}/<a href="http://Version.cpp.in" target="_blank">Version.cpp.in</a> )<br>
set( version_file_out ${generated_source_dir}/Main/Version.cpp )<br>
<br>
add_custom_command(<br>
OUTPUT ${version_file_out}<br>
COMMAND ${CMAKE_COMMAND}<br>
-D IN_FILE=${version_file_in}<br>
-D OUT_FILE=${version_file_out}<br>
-D GIT_EXECUTABLE=${GIT_EXECUTABLE}<br>
-D BUILD_VERSION=${ZIOSK_BUILD_VERSION}<br>
-P ${CMAKE_CURRENT_SOURCE_DIR}/build_version_header.cmake<br>
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}<br>
)<br>
<br>
source_group( Generated FILES ${version_file_out} )<br>
list( APPEND source_files ${version_file_out} )<br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" 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" 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" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" 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" 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" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
</div>
</span></font></div>
</div>
-- <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>