<div dir="ltr">Please excuse the brevity of this response, but a couple of links you may want to read which may be somewhat related or provide further ideas for you:<div><br></div><div><ul><li>The new <a href="https://cmake.org/cmake/help/git-master/module/FetchContent.html">FetchContent module</a> which is on master but not yet in any release. I expect it will be available in 3.11.0 when it comes out. This offers an alternative way of incorporating dependencies in a way which will make them all appear directly in an IDE just like the rest of the project.</li><li>Invoking a nested build to provide something that can be used immediately in the main CMake run is discussed in <a href="https://stackoverflow.com/q/36084785/1938798">this stackoverflow question and answer</a> (by me). Pay special attention to the comments in the Updated section about what can happen if a CMake run is aborted/interrupted, leaving the main build trapped by the sub-build.</li></ul><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 21, 2018 at 9:16 PM, Kai Wolf <span dir="ltr"><<a href="mailto:kai.wolf@gmail.com" target="_blank">kai.wolf@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
a common approach for dealing with larger dependencies in a project is using a superbuild approach, where all dependencies get downloaded in a separate repository using ExternalProject_Add() and the actual project is included as a sub repository (e.g. using git submodules) and also build as an external project [1], [2], [3]. This is necessary since external projects don’t play well as a direct dependency for internal targets, as the external projects won’t be created and available until build time, whereas CMake needs some information already at configure time for creating a proper build system.<br>
<br>
As discussed previously on this mailing list this approach has some significant drawbacks: Since the actual project is also build as an external project, CMake treats it as an external source respectively and IDE support is not available. One possible solution to this problem is to let the outer project generate a cache file which subsequently can be used in the actual project to configure all paths to the previously downloaded and built external dependencies:<br>
<br>
+----------------+<br>
| Superbuild | ----> generates init-cache.cmake<br>
+----------------+<br>
<br>
+----------------+<br>
| actual project | ----> uses: cmake -C init-cache.cmake<br>
+----------------+<br>
<br>
However, this means we now need two steps to configure and build the actual project and also cannot easily maintain the external dependencies within one large project.<br>
<br>
After thinking about this for a while I came up with the following hackish solution and would like to ask you, if you see any drawback in using this. Basically all I’m doing is to include the actual project first as a dummy external project and set the external projects as dependencies, thus they’ll get built beforehand and in the BUILD_COMMAND of the actual project I’m calling CMake to the project’s CMakeLists.txt again to trigger a reconfigure, writing a cache file and set a specific variable |project_deps_installed| which is used as an indicator in the CMakeLists. configuration to include the actual project via add_subdirectory(). For instance:<br>
<br>
CMakeLists.txt:<br>
option(BUILD_MYPROJECT „Build the actual project“ ON)<br>
if(BUILD_MYPROJECT)<br>
if(project_deps_installed)<br>
include(${CMAKE_CURRENT_<wbr>BINARY_DIR}/init-cache.cmake)<br>
add_subdirectory(MyProject)<br>
else()<br>
include(External_project)<br>
endif()<br>
endif()<br>
<br>
External_project.cmake<br>
ExternalProject_Add(MyProject<br>
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/<wbr>MyProject<br>
BUILD_COMMAND ${CMAKE_COMMAND} -E chdir ${CMAKE_CURRENT_BINARY_DIR}<br>
${CMAKE_COMMAND} ${CMAKE_CURRENT_SOURCE_DIR}<br>
INSTALL_COMMAND „"<br>
DEPENDS ${external_deps})<br>
<br>
write_cmake_cache_file(„${<wbr>cache_script}“ „${cache_args}“)<br>
set(project_deps_installed TRUE CACHE BOOL „“)<br>
<br>
As a result, all external dependencies get build and installed via ExternalProject_Add() and the actual project is configured properly and included via add_subdirectory(), thus it can continue using find_package() as usual and will be pointed to the previously configured dependencies. So far, I haven’t found any downside to this and consider making this part of CMake itself, in case you don’t see any problems using this approach?<br>
<br>
<br>
Thanks in advance for your input.<br>
<br>
<br>
[1] <a href="https://github.com/OpenChemistry/openchemistry" rel="noreferrer" target="_blank">https://github.com/<wbr>OpenChemistry/openchemistry</a><br>
[2] <a href="https://github.com/MITK/MITK" rel="noreferrer" target="_blank">https://github.com/MITK/MITK</a><br>
[3] <a href="https://github.com/SuperElastix/SuperElastix" rel="noreferrer" target="_blank">https://github.com/<wbr>SuperElastix/SuperElastix</a><br>
<br>
<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/<wbr>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/<wbr>support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>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/<wbr>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/<wbr>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/<wbr>listinfo/cmake</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div></div></div></div></div></div></div>
</div>