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

[Florent Castelli]

On 01/09/2017 20:40, Alex Turbov wrote:
> Hi Robert,
>
>
> On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey 
> <rcdailey.lists at gmail.com <mailto:rcdailey.lists at gmail.com>> wrote:
>
>
>     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. 
>
>
> In my project I have a bunch of components and do one exported target 
> per component
> exactly by the mentioned reason -- user didn't ask for others...
>
>     Does this go against any design
>     principles? 
>
>
> As far as I know, there are no clear design principles :) (yet, at 
> least nowadays) -- at least doing
> a lot of CMake projects since 2009, I've never seen an explicit list 
> of them %)
> IMHO, there is a lack of "official guildelines" (or it is really hard 
> to search for 'em)
>
>     Assuming this really happens, are there any negative side
>     effects?
>
>
> I could see the impact on build time only in this case... and for me 
> the most obvious is increasing
> time to process the lists (which is for some reasons really slow on 
> Windows, at least in our
> build farm which uses vargant and VirtualBox images)
> (but I don't have any particular numbers, cuz never implemented the 
> first approach)

Well, there's no impact on build time. The module will provide IMPORTED 
targets, if they are not used,
they won't be used in the solution / Makefile. And I don't think CMake 
has any significant bottleneck
on having just a few more IMPORTED targets around from a find_package() 
module.

Components might be important for an old "FindFoo.cmake" module where 
you don't want to find
a lot more libraries in your path, not so much for a "FooConfig.cmake" 
which is a "dumb" file that
just defines a lot of targets and their properties.

/Florent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170901/bb5712ef/attachment-0001.html>