[cmake-developers] target_link_libraries: Allow use with targets in other directories
Hi,
since my first try of relaxing the limitation that target_link_libraries
may not be called in other directories was reverted due to a use case
that was not fully covered, a more promising approach has been developed
after a long but very insightful discussion which I wanted to present
here to collect some feedback from you.
In order to allow linking from another directory, the actual directory
where the RHS target was created (and should be found later via lookup)
needs to be encoded. The proposed solution would add a new syntax for
this (note the similarity to C++ lambda expressions):
[target_name]@{subdir}
This is necessary since it is not possible at all to use generator
expressions. The syntax would be specific to values in the
[INTERFACE_]LINK_LIBRARIES properties and not be meaningful elsewhere
(besides target_link_libraries arguments used to populate the
properties). Future extensions to this may include encoding of more
properties:
[target_name]@{prop1:value1;prop2:value2;...}
Special characters such as : and = will be disallowed now. Furthermore,
lists of targets may also be handled in some future extension:
[target1]@{"subdir"};[target2]@{"subdir"} => [target1;target2]@{"subdir"}
Note that these two extensions may or may not be included in some future
version. Our primary focus here lies on the basic use case of encoding
the directory property without limiting future generalizations. More
details and an in-depth discussion about the problem can be found in
this issue (https://gitlab.kitware.com/cmake/cmake/issues/17943). Please
share your thoughts regarding the proposed syntax and let us know
potential problems that should be tackled.
Best regards,
Patrick Stotko
--
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-developers
Re: [cmake-developers] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing
I've reproduced the error. A possible fix would be to extend pkg_check_module and pkg_search_module to allow globally imported targets, i.e. to add an IMPORTED_GLOBAL_TARGET or GLOBAL keyword (where the latter is only usable together with IMPORTED_TARGET) to allow similar control as add_library. Essentially, adding GLOBAL here https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindPkgConfig.cmake#L232 immediately solves the problem, so it's indeed related to target visibility. Therefore, I think this is intended behavior and the logic for the RHS target is correct. Maybe we should open an issue and discuss the design of the fix there together with Brad King and the others. Best regards, Patrick Stotko On 30.06.2018 23:03, Patrick Stotko wrote: It seems that CMake does not find PkgConfig::GooCanvas because it is imported but not globally imported, i.e. it is maybe a visibility problem. For reference, the relaxation of this limitation (https://gitlab.kitware.com/cmake/cmake/merge_requests/2040) is covered by this additional check for the LHS target: https://gitlab.kitware.com/cmake/cmake/blob/c9349cc1b94a08b4f5ed86a397e72ceed50847dd/Source/cmTargetLinkLibrariesCommand.cxx#L383 Maybe a corresponding check for locally imported RHS targets is missing here: https://gitlab.kitware.com/cmake/cmake/blob/c9349cc1b94a08b4f5ed86a397e72ceed50847dd/Source/cmTargetLinkLibrariesCommand.cxx#L396 Best regards, Patrick Stotko Am 30.06.2018 um 21:15 schrieb Rolf Eike Beer: * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. I played a bit around with that as I hope it would simplify some things in OSM2go, but it looks there are still some limitations: in main: add_library(osm2go_lib ...) add_subdirectory(sub) in sub: pkg_search_module(GooCanvas REQUIRED IMPORTED_TARGET goocanvas) target_sources(osm2go_lib PRIVATE src/platforms/gtk/canvas_goocanvas.cpp ) target_link_libraries(osm2go_lib PRIVATE PkgConfig::GooCanvas) Breaks: CMake Error at CMakeLists.txt:43 (add_library): Target "osm2go_lib" links to target "PkgConfig::GooCanvas" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? Is this intended to work? There is an easy workaround, but it feels nasty: add_library(osm2go_x_lib INTERFACE) target_link_libraries(osm2go_x_lib INTERFACE PkgConfig::GooCanvas) target_link_libraries(osm2go_lib PRIVATE osm2go_x_lib) -- 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-developers
Re: [cmake-developers] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing
It seems that CMake does not find PkgConfig::GooCanvas because it is imported but not globally imported, i.e. it is maybe a visibility problem. For reference, the relaxation of this limitation (https://gitlab.kitware.com/cmake/cmake/merge_requests/2040) is covered by this additional check for the LHS target: https://gitlab.kitware.com/cmake/cmake/blob/c9349cc1b94a08b4f5ed86a397e72ceed50847dd/Source/cmTargetLinkLibrariesCommand.cxx#L383 Maybe a corresponding check for locally imported RHS targets is missing here: https://gitlab.kitware.com/cmake/cmake/blob/c9349cc1b94a08b4f5ed86a397e72ceed50847dd/Source/cmTargetLinkLibrariesCommand.cxx#L396 Best regards, Patrick Stotko Am 30.06.2018 um 21:15 schrieb Rolf Eike Beer: * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. I played a bit around with that as I hope it would simplify some things in OSM2go, but it looks there are still some limitations: in main: add_library(osm2go_lib ...) add_subdirectory(sub) in sub: pkg_search_module(GooCanvas REQUIRED IMPORTED_TARGET goocanvas) target_sources(osm2go_lib PRIVATE src/platforms/gtk/canvas_goocanvas.cpp ) target_link_libraries(osm2go_lib PRIVATE PkgConfig::GooCanvas) Breaks: CMake Error at CMakeLists.txt:43 (add_library): Target "osm2go_lib" links to target "PkgConfig::GooCanvas" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? Is this intended to work? There is an easy workaround, but it feels nasty: add_library(osm2go_x_lib INTERFACE) target_link_libraries(osm2go_x_lib INTERFACE PkgConfig::GooCanvas) target_link_libraries(osm2go_lib PRIVATE osm2go_x_lib) -- 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-developers
Re: [cmake-developers] target_link_libraries not callable from other directory scopes
Am 27.04.2018 um 15:13 schrieb Brad King: On 04/26/2018 07:18 PM, Craig Scott wrote: Perhaps it was an oversight that newer target_... commands don't have the same restriction as target_link_libraries(), but it is a very useful oversight! As the linked blog article explains, it allows much better modularity of the project. Yes, and usage requirements make non-local effects commonplace anyway. Those didn't exist when the `target_link_libraries` restriction was first put in place. Back then *everything* that affected a target's build was in its own `CMakeLists.txt` file. Being able to use add_subdirectory() instead of include() allows the subdirectory to be more isolated The original restriction was to prevent parent and sibling directories from affecting a target's build. We didn't think much about subdirectories as a way of incrementally accumulating build information for a target. I think it would be fine to lift the restriction if there is no technical hurdle. -Brad As far as I can see, the code that prevents linking from other directories starts here: https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmTargetLinkLibrariesCommand.cxx#L369 The check for imported targets should be definitly kept since users should still not be able to modify third party targets. Maybe FindLocalNonAliasTarget() can be replaced with something like FindNonAliasTarget() or FindGlobalNonAliasTarget() to catch aliases. I am not sure whether such a thing already exists or must be implemented. We can also continue the discussion at GitLab to avoid bothering the others with such technical details if you like. Best regards, Patrick Stotko -- 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-developers
[cmake-developers] target_link_libraries not callable from other directory scopes
Hi, this nice post (https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/) mentions some modern usage of target_sources(), but also shows some discrepancy between target_link_libraries and the remaining target_* functions. In particlar, CMake does not allow linking to a target outside its creation scope whereas all the other ones do. There exists a workaround with include(), but it seems not the correct and clean way to handle this. So I think lifting this limitation would escepially help large-scale projects and improve modularization by handling third-party dependencies in the specific modules (as long as only this particular module needs it). So what is your experience regarding this linking restriction, especially in larger projects? I also opened an issue for this (see https://gitlab.kitware.com/cmake/cmake/issues/17943). Best regards, Patrick Stotko -- 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-developers
