<div dir="ltr">You need to manually write your config module which takes care of the dependencies. Of course you will still use the generated exports, too.<div><br><div><span style="font-size:12.8px">For now let's say `ome-common` has one dependency: `omedep` and its config-module, `omedep-config.cmake` creates the imported lib target `omedep::omedep`. The in `ome-common`'s CMakeLists.txt:</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> target_link_libraries(ome-common PUBLIC omedep::omedep)</span></div><div><span style="font-size:12.8px"> install(TARGETS ome-common</span><br style="font-size:12.8px"><span style="font-size:12.8px"> EXPORT ome-common-targets </span><span style="font-size:12.8px">....)</span></div><div><span style="font-size:12.8px"> install(EXPORT ome-common-targets</span><br></div><div><span style="font-size:12.8px"> DESTINATION c</span><span style="font-size:12.8px">make/ome-common)</span><br></div><div><span style="font-size:12.8px"> install(FILES ome-common-config.cmake DESTINATION cmake/ome-common)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> The `ome-common-config.cmake` should look like this:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> include(CMakeFindDependencyMacro)</span></div><div><span style="font-size:12.8px"> find_dependency(omedep)</span></div><div><span style="font-size:12.8px"> include(${CMAKE_CURRENT_LIST_DIR}/ome-common-targets.cmake)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Note: for CMake versions < 3.0 you need to use `find_package` instead of `find_dependency`.</span></div><div><br></div><div>Okay, so that's the solution if `ome-common`'s dependency creates an imported lib target.</div><div><br></div><div>If `omedep` has an oldschool config-module which provides only variables like OMEDEP_LIBRARIES containing absolute paths, then these paths will be hardcoded in `ome-common-targets.cmake`. In this case the recommended method is to convert these paths to relative paths in a postprocess step after installation.</div><div>See this: <a href="https://gist.github.com/tamaskenez/7ca4cba352525985ea70">https://gist.github.com/tamaskenez/7ca4cba352525985ea70</a> as an example for such a script.</div><div><br></div><div>Of course this can only be used if `omedep` is a dependency which is installed into the same install tree as `ome-common`.</div><div>If you have a dependency in a separate install-tree which does not create imported lib targets then you need to do it yourself both in `ome-common`'s CMakeLists.txt and config-modules. This is not a trivial operation but always can be done with more or less additional logic. For a simple case where `omedep` consists of a single library file:</div><div><br></div><div>`ome-common`'s CMakeLists.txt:</div><div><br></div><div> find_package(omedep REQUIRED)</div><div><div> add_library(ome-common::omedep STATIC IMPORTED) # STATIC or SHARED or UNKNOWN</div><div> set_target_properties(ome-common::omedep PROPERTIES</div><div> INTERFACE_INCLUDE_DIRECTORIES ${OMEDEP_INCLUDE_DIRS}</div><div> IMPORTED_LINK_INTERFACE_LANGUAGES "C"</div><div> IMPORTED_LOCATION ${OMEDEP_LIBRARIES} # a single library</div><div> )<br></div></div><div><div><span style="font-size:12.8px"> target_link_libraries(ome-common PUBLIC ome-common::omedep)</span></div></div><div><span style="font-size:12.8px"> ...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">which should be repeated in `ome-common-config.cmake`:</span></div><div><br></div><div><div><span style="font-size:12.8px"> include(CMakeFindDependencyMacro)</span></div><div><span style="font-size:12.8px"> find_dependency(omedep)</span></div><div><div> set_target_properties(ome-common::omedep PROPERTIES</div><div> INTERFACE_INCLUDE_DIRECTORIES ${OMEDEP_INCLUDE_DIRS}</div><div> IMPORTED_LINK_INTERFACE_LANGUAGES "C"</div><div> IMPORTED_LOCATION ${OMEDEP_LIBRARIES} # a single library</div><div> )<br></div></div><div></div><div><span style="font-size:12.8px"> include(${CMAKE_CURRENT_LIST_DIR}/ome-targets.cmake)</span></div></div><div><span style="font-size:12.8px"><br></span></div><div>Things get more complicated when OMEDEP_LIBRARIES has per-config variants or further dependencies. You can check the generated `ome-common-targets.cmake` and `ome-common-targets-Debug/Relase.cmake` files for an example on how to set up such an imported lib target.<br><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 14, 2015 at 7:19 PM, Nicholas Braden <span dir="ltr"><<a href="mailto:nicholas11braden@gmail.com" target="_blank">nicholas11braden@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Instead of using FOO_INCLUDE_DIR, I believe you should use<br>
target_include_directories() with the INTERFACE or PUBLIC options -<br>
this will export the include directories properly and they will be<br>
used when someone target_link_library()s your exported target.<br>
<a href="https://cmake.org/cmake/help/latest/command/target_include_directories.html?highlight=INTERFACE" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/latest/command/target_include_directories.html?highlight=INTERFACE</a><br>
<br>
There seems to be a section in the documentation on making sure your<br>
packages are relocatable:<br>
<a href="https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-relocatable-packages" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-relocatable-packages</a><br>
<br>
See also:<br>
<a href="https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html</a><br>
<br>
As for recursively finding packages, I honestly don't know on this<br>
front. I would imagine that everything might work if everything was<br>
using exported/imported targets, but I'm not sure. The problem is that<br>
you have to consider what happens if you relocate your relocatable<br>
package to a system that doesn't have the dependencies installed. I<br>
don't think exported/imported targets or relocatable packages can<br>
solve that problem easily, but I am not very knowledgeable in this<br>
area myself.<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Nov 14, 2015 at 5:53 AM, Roger Leigh <<a href="mailto:rleigh@codelibre.net">rleigh@codelibre.net</a>> wrote:<br>
> Hi,<br>
><br>
> I'm wanting to create -config scripts for my libraries so that dependent<br>
> projects can find them with find_package and use them transparently. I have<br>
> a number of header-only and shared/static libs, and I'd like to retain their<br>
> relationships, plus any additional libraries they are linked with.<br>
><br>
> I was previously using hand-crafted templates, e.g. with this type of<br>
> generated structure:<br>
><br>
> ---------------------------------------------------------------------------<br>
> set(OME_COMMON_FOUND TRUE)<br>
><br>
> set(OME_COMMON_VERSION "5.2.0-pre0-7-gfc53ca3")<br>
> set(OME_COMMON_VERSION_MAJOR "5")<br>
> set(OME_COMMON_VERSION_MINOR "2")<br>
> set(OME_COMMON_VERSION_PATCH "0")<br>
> set(OME_COMMON_VERSION_EXTRA "-pre0-7-gfc53ca3")<br>
><br>
> find_path(OME_COMMON_INCLUDE_DIR ome/common/module.h HINTS<br>
> "/tmp/split/include")<br>
> find_library(OME_COMMON_LIBRARY NAMES ome-common libome-common HINTS<br>
> "/tmp/split/lib")<br>
> ---------------------------------------------------------------------------<br>
><br>
> They unfortuately did not handle interface targets or public library<br>
> dependencies required by use in the headers. I've switched to using<br>
> install(EXPORT):<br>
><br>
> <a href="https://github.com/rleigh-dundee/ome-common-cpp/blob/develop/lib/ome/common/CMakeLists.txt#L123" rel="noreferrer" target="_blank">https://github.com/rleigh-dundee/ome-common-cpp/blob/develop/lib/ome/common/CMakeLists.txt#L123</a><br>
> ---------------------------------------------------------------------------<br>
> target_link_libraries(ome-common ome-compat<br>
> ${Boost_LOG_SETUP_LIBRARY_RELEASE}<br>
> ${Boost_LOG_LIBRARY_RELEASE}<br>
> ${Boost_FILESYSTEM_LIBRARY_RELEASE}<br>
> ${Boost_SYSTEM_LIBRARY_RELEASE}<br>
> ${LibDl_LIBRARIES}<br>
> ${XercesC_LIBRARIES})<br>
><br>
> set_target_properties(ome-common PROPERTIES LINKER_LANGUAGE CXX)<br>
> set_target_properties(ome-common PROPERTIES VERSION ${OME_VERSION_SHORT})<br>
><br>
> install(TARGETS ome-common<br>
> EXPORT ome-common-config<br>
> RUNTIME DESTINATION ${CMAKE_INSTALL_FULL_BINDIR}<br>
> LIBRARY DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}<br>
> ARCHIVE DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR})<br>
> install(EXPORT ome-common-config<br>
> DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}/cmake/ome-common)<br>
> ---------------------------------------------------------------------------<br>
><br>
> This does a much better job of the dependencies. It's preserving the<br>
> dependencies for the internal targets, plus the external libraries. However,<br>
> it's lacking:<br>
><br>
> - any setting of the include path via FOO_INCLUDE_DIR, unless it's just not<br>
> done in an obvious manner<br>
> - it's hardcoded the absolute paths of the various boost and xerces libs;<br>
> I'd like it to be relocatable so it can work in a superbuild and continue to<br>
> work after moving elsewhere<br>
> - it doesn't appear to recursively find needed import targets, e.g. I need<br>
> to find_package(ome-compat) before find_package(ome-common); it would be<br>
> nice if this was transparent so the user doesn't need to do this<br>
><br>
> I'd be interested to know if anyone else has run into these issues, and if<br>
> so what your solutions were? I'm quite new to this part of cmake, so it may<br>
> well just be I'm not doing things exactly as expected.<br>
><br>
> Would it be easier to construct the template myself and then call<br>
> find_package for the external libs to avoid hardcoding the paths? Is it<br>
> safe to recursively call find_package inside find_package?<br>
><br>
><br>
> Thanks all,<br>
> Roger<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:<br>
> <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<br>
> 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<br>
> <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="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><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="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>