[cmake-developers] How should config packages handle components?

Robert Dailey rcdailey.lists at gmail.com
Tue Sep 5 15:33:32 EDT 2017


In the case where I'm exporting 1 target.cmake script per component
for a single package, could someone provide an example on how to
manage dependencies? There are 2 types of dependencies:

1. Dependencies on external packages
2. Cross-dependencies within the same package (i.e. on other
components in the same package)

The cmake-packages doc kind of goes over #1, but #2 doesn't seem to
have examples.

On Fri, Sep 1, 2017 at 1:21 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> First of all, I want to apologize for including the developer list.
> Maybe I'm not being patient enough, but it seems like every post I've
> made on the normal users list doesn't get any attention.
>
> Secondly, the cmake-packages portion of the cmake documentation
> doesn't go into a ton of detail about components, but it does give an
> example towards the bottom of how you export targets for components.
> This leads to my questions:
>
> When defining the target exports via install(TARGET foo EXPORT
> foo-export), is it recommended for all components to collectively
> export as 1 target.cmake script? Or is it better to have 1
> target.cmake script per component? If we use Boost as an example, the
> latter would mean having:
>
> boost-config.cmake
> boost-target-filesystem.cmake
> boost-target-thread.cmake
> ...etc...
>
> This means that boost-config.cmake would "include()" only the relevant
> target cmake scripts based on the provided COMPONENTS list, I assume?
>
> Which is the better approach here and why?
>
> One problem I thought of with the former (one big target.cmake with
> all import targets in there) is that if you only ask for a subset of
> components in find_package(), you will still get all of them since all
> imports are defined in a single file. Does this go against any design
> principles? Assuming this really happens, are there any negative side
> effects?


More information about the cmake-developers mailing list