Re: [cmake-developers] target_link_libraries not callable from other directory scopes
Craig Scott wrote: > This limitation has been intentional since target_link_libraries was first > created long before the others. It is the oldest of the target_ commands. > The original justification is that we don't want to allow this because it > makes it very easy for non-local commands to drastically change the way a > target is built. That the newer target_ commands allow non-local targets > was an oversight. > > Maybe the limitation could be lifted but I'd like to see a strong > justification and example use case. […] This sounds very much like what I'm doing for OSM2go by other means. This will become simpler once 3.12 is out and object libraries can drag in additional dependencies: https://github.com/osm2go/osm2go/blob/master/src/platforms/gtk/CMakeLists.txt Eike signature.asc Description: This is a digitally signed message part. -- 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
On 04/27/2018 02:36 PM, Patrick Stotko wrote: > We can also continue the discussion at GitLab to avoid bothering the > others with such technical details if you like. Fine with me. I mainly wanted it brought up here to gain more attention. Interested followers can now jump to the issue: https://gitlab.kitware.com/cmake/cmake/issues/17943 -Brad -- 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
Re: [cmake-developers] target_link_libraries not callable from other directory scopes
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 -- 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
On Thu, Apr 26, 2018 at 4:22 AM, Patrick Stotko < sto...@informatik.uni-bonn.de> wrote: > Hi, > > this nice post (https://crascit.com/2016/01/3 > 1/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). > > And from Brad's comment on that gitlab issue: This limitation has been intentional since target_link_libraries was first created long before the others. It is the oldest of the target_ commands. The original justification is that we don't want to allow this because it makes it very easy for non-local commands to drastically change the way a target is built. That the newer target_ commands allow non-local targets was an oversight. Maybe the limitation could be lifted but I'd like to see a strong justification and example use case. 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. Extracting part of one of my comments on the above-linked article: For a real world example, consider a library or executable that has many source files and where some functionality is optional and/or depends on the availability of some external toolkit. Code related to such an optional feature can be put in its own sub directory and conditionally included in the library or executable. That sub directory can hold all the logic related to that feature, including any external libraries that need to be linked in. This is good modularisation since it localised the logic instead of polluting the main CMakeLists.txt file. It isn’t always possible or desirable to split out such an optional feature to its own library (eg to ensure aspects of the implementation are not revealed by exported symbol names or similar concerns). Thus, being able to incorporate it directly into the main library or executable could be a requirement. Being able to still isolate everything related to that feature in its own sub directory can help keep things organised and easy to manage. Being able to use add_subdirectory() instead of include() allows the subdirectory to be more isolated, since any variables changed in the subdirectory's scope won't affect the current scope. For new users, add_subdirectory() also tends to feel more natural than include() and lead to fewer errors. When using include(), you have to be very careful to use CMAKE_CURRENT_LIST_DIR instead of CMAKE_CURRENT_SOURCE_DIR whenever you need to construct an absolute path to something in the same (source) directory, but new users often seem to not really know about CMAKE_CURRENT_LIST_DIR. There's also no corresponding binary directory if you use include(), unlike add_subdirectory() which nicely reproduces the source directory structure in the build directory. Basically you can do things with include() if you are careful, but add_subdirectory() is more intuitive and more forgiving. The current restriction on target_link_libraries() is the one hold-out for being able to make subdirectories fully self-contained as far as building things goes. Adding to the above quoted comment from the article, my experience on some large projects has been that I can modularise optional parts of libraries quite well using the various target_...() commands, but then I have to duplicate some of the logic just because I still have to put the target_link_libraries() call in the same directory as where the target is defined. That's been a thorn in my side, because the modularity made possible by target_sources() and the other target_...() commands have otherwise allowed me to make the CMakeLists.txt files in each subdirectory quite focused on just what that directory supplies. I found that using include() instead of add_subdirectory() was confusing for some of our users, so I tend to prefer to use add_subdirectory() and live with the target_link_libraries() calls being leaked to the main directory, but I would really love to avoid having to do that. -- Craig Scott Melbourne, Australia https://crascit.com -- 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
[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
