[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: Re: [CMake] [cmake-developers] How should config packages handle components?
From: Florent Castelli <florent.castelli () gmail ! com>
Date: 2017-09-01 19:47:03
Message-ID: 506b6a64-f04c-7470-1253-e352e9a5bebf () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 01/09/2017 20:40, Alex Turbov wrote:
> Hi Robert,
>
>
> On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey
> <rcdailey.lists@gmail.com <mailto:rcdailey.lists@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
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/09/2017 20:40, Alex Turbov wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANktQtvJaAxmNaLfChG05KRdzT-n0DAogXY6cOwMUD=VyuOKTw@mail.gmail.com">
<div dir="ltr">Hi Robert,<br>
<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Sep 1, 2017 at 9:21 PM,
Robert Dailey <span dir="ltr"><<a
href="mailto:rcdailey.lists@gmail.com" target="_blank"
moz-do-not-send="true">rcdailey.lists@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
One problem I thought of with the former (one big
target.cmake with<br>
all import targets in there) is that if you only ask for a
subset of<br>
components in find_package(), you will still get all of
them since all<br>
imports are defined in a single file. </blockquote>
<div><br>
</div>
<div>In my project I have a bunch of components and do one
exported target per component</div>
<div>exactly by the mentioned reason -- user didn't ask for
others...<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Does
this go against any design<br>
principles? </blockquote>
<div><br>
</div>
<div>As far as I know, there are no clear design principles
:) (yet, at least nowadays) -- at least doing</div>
<div>a lot of CMake projects since 2009, I've never seen an
explicit list of them %)<br>
</div>
<div>IMHO, there is a lack of "official guildelines" (or it
is really hard to search for 'em)<br>
</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Assuming
this really happens, are there any negative side<br>
effects?<br>
</blockquote>
<div><br>
</div>
<div>I could see the impact on build time only in this
case... and for me the most obvious is increasing</div>
<div>time to process the lists (which is for some reasons
really slow on Windows, at least in our</div>
<div>build farm which uses vargant and VirtualBox images)</div>
<div>(but I don't have any particular numbers, cuz never
implemented the first approach)<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Well, there's no impact on build time. The module will provide
IMPORTED targets, if they are not used,<br>
they won't be used in the solution / Makefile. And I don't think
CMake has any significant bottleneck<br>
on having just a few more IMPORTED targets around from a
find_package() module.<br>
<br>
Components might be important for an old "FindFoo.cmake" module
where you don't want to find<br>
a lot more libraries in your path, not so much for a
"FooConfig.cmake" which is a "dumb" file that<br>
just defines a lot of targets and their properties.<br>
<br>
/Florent<br>
</body>
</html>
--
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic