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

[Robert Dailey]

On Fri, Sep 1, 2017 at 1:40 PM, Alex Turbov <i.zaufi at gmail.com> wrote:
> Hi Robert,
>
>
> On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey <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)

Thanks for the quick response. The "official guidelines" or "package
standard" is really exactly what we need I think. What worries me the
most is that it seems like this is deep knowledge that is stuck in the
brains of folks like Brad King and David Cole. I think somehow getting
a knowledge dump from them into a documentation page would be a
valuable task. I think for something as complex and variable as
packages in CMake (install process in general) deserves some
standardization, because we need the ability to distinguish between
practices that we should follow for legacy (backward compatibility)
reasons, non-cmake project reasons, and fully "modern" cmake packages.