[CMake] Shortcomings with exporting and importing targets

[Alex Turbov]

> 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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190725/8fa2cdb9/attachment.html>