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
