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

[Alex Turbov]

I've started to use CMake a quite long time ago, and do not search for
"standards" or "guidelines" anymore %)
But I could mention some chapters in the official documentation (in the
"Reference Manuals" section) which are really full of "secret knowledge",
but the problem is that they are too complicated for newcomers %) but
personally I read them many many times before and each time found smth
"new" to me :)

I would say that after a couple of years I started to feel comfortable w/
CMake -- when I've used almost all offered features in a different set of
platform and generators.

On Fri, Sep 1, 2017 at 9:49 PM, Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170901/d3f1109a/attachment.html>