On 01/09/2017 20:40, Alex Turbov wrote:
Hi Robert,


On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey <rcdailey.li...@gmail.com <mailto:rcdailey.li...@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
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Reply via email to