[CMake] Shortcomings with exporting and importing targets

[Robert Maynard]

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 at 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 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