[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: Re: [CMake] Shortcomings with exporting and importing targets
From: Alex Turbov <i.zaufi () gmail ! com>
Date: 2019-07-25 15:50:26
Message-ID: CANktQtt_E_PCQrjNzH+4wGrCDa29gF0zcDVeb3Udqu8pxiJ4CQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Unfortunately, your approach won't work %(
- first of all to write a `*-config.cmake` file the user gonna use
`configure_package_config_file` (which is end up w/ `configure_file`).
there is no place to use `file(GENERATE...)` since its result appears too
late...
- Ok, I can imagine that in the middle of `*-config.cmake` one can do
`include(genex-expanded-blah-blah.cmake)` which is the result of
`file(GENERATE...)` from the CMake run. But, the next problem is to match
imported targets (obviously generated as a list variable) to the package
names, versions, and components suitable for `find_package`...
- The next problem: some finders could be tuned via variables (e.g.
`OPENSSL_USE_STATIC_LIBS`, `Boost_USE_MULTITHREADED`, &etc) or even worse
-- finder was given a path hint to load particular build of the third-party
dependency (e.g. `XXX_ROOT_DIR`)...
So, I'd be happy if CMake could take care of imported targets (loaded via
`find_package`) for me and allows me to easily generate an export targets
file with required `find_packages` *really used* by my target...
On Thu, Jul 25, 2019 at 6:22 PM Robert Maynard <robert.maynard@kitware.com>
wrote:
> In general you match every find_package call in your project with one
> in your generate config file. If you have complicated conditional
> dependencies you might be able to use file(GENERATE to determine which
> ones will be used.
>
>
> On Thu, Jul 25, 2019 at 11:02 AM Alex Turbov <i.zaufi@gmail.com> wrote:
> >
> > > It is than up to each project to generate an Config module that does
> > the required find_package calls to re-locate ZLIB.
> >
> > Problems begin when mentioned dependencies are wrapped into generator
> expressions (e.g. $<TARGET_NAME_IF_EXISTS:ZLIB::ZLIB> or smth even more
> complicated) -- how do I know what `find_packages` to include to my
> `*-config.cmake`??
> >
> > On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard <
> robert.maynard@kitware.com> wrote:
> >>
> >> target_link_libraries() when given an explicit path+filename as PUBLIC
> >> ( not PRIVATE ) will be part of the transitive dependencies. An
> >> explicit path+filename is not a target to CMake, nor will CMake
> >> compute that it maps to an existing target ( be it imported or a
> >> 'normal' target ).
> >>
> >> > This makes me think that install(TARGETS ...) not supporting imported
> targets is likely an oversight by the CMake developers
> >>
> >> When exporting targets CMake exports what import targets something it
> >> depends on. So if you have target_link_libraries(my_target PUBLIC
> >> ZLIB::ZLIB) CMake when exporting my_target will export it depends on
> >> ZLIB::ZLIB. It does this so that export information is machine
> >> relocatable.
> >> It is than up to each project to generate an Config module that does
> >> the required find_package calls to re-locate ZLIB.
> >>
> >> On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick <
> benshadwick@gmail.com> wrote:
> >> >
> >> > As a followup to my previous email dated 7/15/19, I learned from a
> co-worker this week that if Project A's target_link_libraries() links
> against an explicit path+filename of an external library, a subsequent
> install(TARGETS ...) command will actually include that dependency in the
> exported target for Library A1, such that it will be picked up as a
> transitive dependency when later linking Library A1 into a binary in
> Project B.
> >> >
> >> > This makes me think that install(TARGETS ...) not supporting imported
> targets is likely an oversight by the CMake developers. This ought to be
> fixed, because it effectively discourages people from following the "modern
> CMake" approach of using targets wherever possible.
> >> > --
> >> >
> >> > 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:
> >> > https://cmake.org/mailman/listinfo/cmake
> >> --
> >>
> >> 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:
> >> https://cmake.org/mailman/listinfo/cmake
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>Unfortunately, your approach won't work \
%(</div><div><br></div><div>- first of all to write a `*-config.cmake` file the user \
gonna use `configure_package_config_file` (which is end up w/ `configure_file`). \
there is no place to use `file(GENERATE...)` since its result appears too \
late...<br></div><div>- Ok, I can imagine that in the middle of `*-config.cmake` one \
can do `include(genex-expanded-blah-blah.cmake)` which is the result of \
`file(GENERATE...)` from the CMake run. But, the next problem is to match imported \
targets (obviously generated as a list variable) to the package names, versions, and \
components suitable for `find_package`...</div><div>- The next problem: some finders \
could be tuned via variables (e.g. `OPENSSL_USE_STATIC_LIBS`, \
`Boost_USE_MULTITHREADED`, &etc) or even worse -- finder was given a path hint to \
load particular build of the third-party dependency (e.g. \
`XXX_ROOT_DIR`)...</div><div><br></div><div>So, I'd be happy if CMake could take \
care of imported targets (loaded via `find_package`) for me and allows me to easily \
generate an export targets file with required `find_packages` *really used* by my \
target...</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Thu, Jul 25, 2019 at 6:22 PM Robert Maynard <<a \
href="mailto:robert.maynard@kitware.com">robert.maynard@kitware.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In general you match \
every find_package call in your project with one<br> in your generate config file. If \
you have complicated conditional<br> dependencies you might be able to use \
file(GENERATE to determine which<br> ones will be used.<br>
<br>
<br>
On Thu, Jul 25, 2019 at 11:02 AM Alex Turbov <<a href="mailto:i.zaufi@gmail.com" \
target="_blank">i.zaufi@gmail.com</a>> wrote:<br> ><br>
> > It is than up to each project to generate an Config module that does<br>
> the required find_package calls to re-locate ZLIB.<br>
><br>
> Problems begin when mentioned dependencies are wrapped into generator \
expressions (e.g. $<TARGET_NAME_IF_EXISTS:ZLIB::ZLIB> or smth even more \
complicated) -- how do I know what `find_packages` to include to my \
`*-config.cmake`??<br> ><br>
> On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard <<a \
href="mailto:robert.maynard@kitware.com" \
target="_blank">robert.maynard@kitware.com</a>> wrote:<br> >><br>
>> target_link_libraries() when given an explicit path+filename as PUBLIC<br>
>> ( not PRIVATE ) will be part of the transitive dependencies. An<br>
>> explicit path+filename is not a target to CMake, nor will CMake<br>
>> compute that it maps to an existing target ( be it imported or a<br>
>> 'normal' target ).<br>
>><br>
>> > This makes me think that install(TARGETS ...) not supporting imported \
targets is likely an oversight by the CMake developers<br> >><br>
>> When exporting targets CMake exports what import targets something it<br>
>> depends on. So if you have target_link_libraries(my_target PUBLIC<br>
>> ZLIB::ZLIB) CMake when exporting my_target will export it depends on<br>
>> ZLIB::ZLIB. It does this so that export information is machine<br>
>> relocatable.<br>
>> It is than up to each project to generate an Config module that does<br>
>> the required find_package calls to re-locate ZLIB.<br>
>><br>
>> On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick <<a \
href="mailto:benshadwick@gmail.com" target="_blank">benshadwick@gmail.com</a>> \
wrote:<br> >> ><br>
>> > As a followup to my previous email dated 7/15/19, I learned from a \
co-worker this week that if Project A's target_link_libraries() links against an \
explicit path+filename of an external library, a subsequent install(TARGETS ...) \
command will actually include that dependency in the exported target for Library A1, \
such that it will be picked up as a transitive dependency when later linking Library \
A1 into a binary in Project B.<br> >> ><br>
>> > This makes me think that install(TARGETS ...) not supporting imported \
targets is likely an oversight by the CMake developers. This ought to be fixed, \
because it effectively discourages people from following the "modern CMake" \
approach of using targets wherever possible.<br> >> > --<br>
>> ><br>
>> > Powered by <a href="http://www.kitware.com" rel="noreferrer" \
target="_blank">www.kitware.com</a><br> >> ><br>
>> > Please keep messages on-topic and check the CMake FAQ at: <a \
href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" \
target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br> >> ><br>
>> > Kitware offers various services to support the CMake community. For \
more information on each offering, please visit:<br> >> ><br>
>> > CMake Support: <a href="http://cmake.org/cmake/help/support.html" \
rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br> \
>> > CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" \
rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br> \
>> > CMake Training Courses: <a \
href="http://cmake.org/cmake/help/training.html" rel="noreferrer" \
target="_blank">http://cmake.org/cmake/help/training.html</a><br> >> ><br>
>> > Visit other Kitware open-source projects at <a \
href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> >> \
><br> >> > Follow this link to subscribe/unsubscribe:<br>
>> > <a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" \
target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br> >> --<br>
>><br>
>> Powered by <a href="http://www.kitware.com" rel="noreferrer" \
target="_blank">www.kitware.com</a><br> >><br>
>> Please keep messages on-topic and check the CMake FAQ at: <a \
href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" \
target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br> >><br>
>> Kitware offers various services to support the CMake community. For more \
information on each offering, please visit:<br> >><br>
>> CMake Support: <a href="http://cmake.org/cmake/help/support.html" \
rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br> \
>> CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" \
rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br> \
>> CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" \
rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br> \
>><br> >> Visit other Kitware open-source projects at <a \
href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> \
>><br> >> Follow this link to subscribe/unsubscribe:<br>
>> <a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" \
target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br> </blockquote></div>
--
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:
https://cmake.org/mailman/listinfo/cmake
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic