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.mayn...@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.za...@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.mayn...@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 < > benshadw...@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 >
-- 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
