[CMake] 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 <robert.maynard at 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190725/c249fb08/attachment.html>