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
