Re: Shortcomings with exporting and importing targets

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Shortcomings with exporting and importing targets

Benjamin Shadwick
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
Reply | Threaded
Open this post in threaded view
|

Re: Shortcomings with exporting and importing targets

Robert Maynard
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Shortcomings with exporting and importing targets

Alex Turbov
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

--

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