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