Re: [CMake] Shortcomings with exporting and importing targets
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 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 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. $ 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/list
Re: [CMake] Shortcomings with exporting and importing targets
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 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. $ 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 > 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 >> 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
Re: [CMake] Shortcomings with exporting and importing targets
> 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. $ 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 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 > 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
Re: [CMake] Shortcomings with exporting and importing targets
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 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
Re: [CMake] add_subdirectory namespaces
Subsequent calls to project() from sub-directories is supported. For calls to project from sub-directories it does everything but set CMAKE_PROJECT_NAME. On Wed, Jul 24, 2019 at 7:29 AM Jason Beach wrote: > > I've been reorganizing / updating our software cmake build. It currently uses > a mixture of Externa Projects and normal target definitions that depend on > the external projects (which has you probably know causes much sorrow and > grief). One of my goals in the reorganization was to replace all the > ExternalProjectAdd statements with FetchContent, however I soon discovered > that some of the external projects declare targets with the same name (i.e. > an uninstall target). These external projects are third party libraries that > are not under our control. > > It appears there's been a suggestion to add namespaces to the > add_subdirectory command: > https://gitlab.kitware.com/cmake/cmake/issues/16414 > > Is that going anywhere? It seems like that would address FetchContent's main > limitation. I guess for the time being I'll use ExternalProject for > thirdparty libraries not under our control and FetchContent for libraries > that are and do a true super build instead of the muddled sort of arrangement > we have now. > > One other kind of not-so-random question-the documentation on the Project > statement is fine if it's in the toplevel CMakeLists.txt (in which case it > defines some project level variables, etc.) but it's silent about what > happens if it's not in the top level CMakeLists.txt. i.e. if I add a library > via add_subdirectory or FetchContent and that library's toplevel > CMakeLists.txt has the project statement, what happens when it's executed? > Is it silently ignored? > > Thanks, > Jason > -- > > 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
