<div dir="ltr"><div><div><div><div><div>In my projects I always, have external dependencies with finder module providing exported (imported in my project) targets, so my targets (one per file) always have a list of `Vendor::target`. Some of them are mine (i.e. your type 2 -- built by the same project).<br><br></div>I wrote a helper module and a function to write an additional `blah-blah-target-depedencies.cmake`. And this is a little bit subtle thing...<br></div>Normally, generated `blah-blah-target.cmake` (where the `blah-blah-target` is the export name used in call to `install(EXPORT)`) to load all installed configurations do the following:<br><br> file(GLOB CONFIG_FILES "${_DIR}/blah-blah-target-*.cmake")<br><br><br></div>so my additional file would be loaded "automatically" :)<br><br></div>My helper function accepts a target name as the only parameter. First of all, it collects all dependencies of the given target and classifies them as internal (same project) and external. It prepares some variables and finally, render a `blah-blah-target-dependencies.cmake` which is a result of the combination of 3 templates:</div><div>0) a base, header+footer and conditionally "include" the next two</div><div>1) import internal dependencies</div><div>2) import external dependencies</div><div><br></div><div>Note templates have random string in final names, so being running (loading) by the same script (`blah-blah-config.cmake`) won't interfere...<br></div><div><br></div><div>As for "prepared variables" there are the following:</div><div>* "internal dependencies" is just a list of target names... having a name is enough to form a `blah-blah-target.cmake` name to be `include()`d, cuz we really know where this file is installed</div><div>* for external dependencies the most important a list of packages, assuming that the initial external (imported) target had the form of `Vendor::target`, and `Vendor` in fact is a package name suitable as the first argument to `find_package()`.</div><div>* other variables related to external targets have a variadic part based on upcased name of the vendor. Example:<br></div><div><br></div><div> set(_blah_blah_PACKAGES ACE;Boost)<br> set(_blah_blah_ACE_VENDOR ACE)<br> set(_blah_blah_ACE_COMPONENTS ace;ssl)<br> set(_blah_blah_ACE_VERSION 5.7.5)<br> set(_blah_blah_BOOST_VENDOR Boost)<br> set(_blah_blah_BOOST_COMPONENTS chrono;filesystem;program_options;thread)<br> set(_blah_blah_BOOST_VERSION 1.65.0)<br><br></div><div>Now about generated `*-config.cmake`. As one may guess it handle targets to import as `COMPONENTS` of `find_package()`, where every component is an exported target name. So this module just `include()` it and check if target appeared:</div><div><br></div><div> # Find components if requested<br> set(blah_FOUND_COMPONENTS)<br> foreach(_module ${blah_FIND_COMPONENTS})<br> # TODO Avoid more than once find? (But be aware that is not a trivial `if` and skip %-)<br> # TODO Make sure component is supported (exists)<br> include(<br> "${CMAKE_CURRENT_LIST_DIR}/blah-${_module}-targets.cmake"<br> OPTIONAL<br> RESULT_VARIABLE blah_${_module}_FOUND<br> )<br><br> if(blah_${_module}_FOUND AND TARGET Blah::${_module})<br> list(APPEND blah_FOUND_COMPONENTS ${_module})<br><br> # Add some interface properties to all found components<br> string(TOUPPER "${_module}" _module_id)<br> string(MAKE_C_IDENTIFIER "${_module_id}" _module_id)<br> set_target_properties(<br> Blah::${_module}<br> PROPERTIES<br> # Set compatible version usage requirement<br> INTERFACE_BLAH_VERSION_MAJOR "${BLAH_VERSION_MAJOR}"<br> # What package to find<br> INTERFACE_BLAH_${_module_id}_PACKAGE_NAME "blah"<br> )<br> set_property(<br> TARGET Blah::${_module}<br> APPEND PROPERTY<br> COMPATIBLE_INTERFACE_STRING BLAH_VERSION_MAJOR<br> )<br> unset(_module_id)<br><br> else()<br> set(blah_${_module}_FOUND NOTFOUND)<br><br> if (blah_FIND_REQUIRED_${_module})<br> list(APPEND blah_NOT_FOUND_REQUIRED_COMPONENTS ${_module})<br> else()<br> list(APPEND blah_NOT_FOUND_COMPONENTS ${_module})<br> endif()<br><br> endif()<br> endforeach()<br> unset(_module)<br></div><div><br></div><div>When all components checked call the final package found/not-found checker:</div><div><br></div><div> check_required_components(blah)</div><div><br></div><div>Yes, this particular implementation have obvious limitations to be named "universal and generic", but it works few years for me w/o problems... (however, I do some improvements from time to time %) It do not handle "plain old library names"... and as I said, all my external packages provide imported targets, where the Vendor name is the package name in fact... so I don't care (while having no reason to improve it for this case... maybe later %).<br></div><div><br></div><div>I'll attach my module (stripping not related and vendor specific parts) for further inspiration... Feel free to ask for details (or more code, if attached doesn't work... probably I miss some functions (from other parts of my framework)).</div><div><br></div><div>Have fun! :)<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 5, 2017 at 10:33 PM, Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the case where I'm exporting 1 target.cmake script per component<br>
for a single package, could someone provide an example on how to<br>
manage dependencies? There are 2 types of dependencies:<br>
<br>
1. Dependencies on external packages<br>
2. Cross-dependencies within the same package (i.e. on other<br>
components in the same package)<br>
<br>
The cmake-packages doc kind of goes over #1, but #2 doesn't seem to<br>
have examples.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Sep 1, 2017 at 1:21 PM, Robert Dailey <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>> wrote:<br>
> First of all, I want to apologize for including the developer list.<br>
> Maybe I'm not being patient enough, but it seems like every post I've<br>
> made on the normal users list doesn't get any attention.<br>
><br>
> Secondly, the cmake-packages portion of the cmake documentation<br>
> doesn't go into a ton of detail about components, but it does give an<br>
> example towards the bottom of how you export targets for components.<br>
> This leads to my questions:<br>
><br>
> When defining the target exports via install(TARGET foo EXPORT<br>
> foo-export), is it recommended for all components to collectively<br>
> export as 1 target.cmake script? Or is it better to have 1<br>
> target.cmake script per component? If we use Boost as an example, the<br>
> latter would mean having:<br>
><br>
> boost-config.cmake<br>
> boost-target-filesystem.cmake<br>
> boost-target-thread.cmake<br>
> ...etc...<br>
><br>
> This means that boost-config.cmake would "include()" only the relevant<br>
> target cmake scripts based on the provided COMPONENTS list, I assume?<br>
><br>
> Which is the better approach here and why?<br>
><br>
> One problem I thought of with the former (one big target.cmake with<br>
> all import targets in there) is that if you only ask for a subset of<br>
> components in find_package(), you will still get all of them since all<br>
> imports are defined in a single file. Does this go against any design<br>
> principles? Assuming this really happens, are there any negative side<br>
> effects?<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="http://public.kitware.com/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/cmake-<wbr>developers</a><br>
</div></div></blockquote></div><br></div>