On 11/06/2012 12:00 PM, Stephen Kelly wrote: > The include directories and compile definitions are set by the > target_link_libraries command.
...by adding generator expressions, right? They won't be evaluated until much later. > It might make sense to add a policy for that > feature, as otherwise the order of include directories would change, eg: > > add_executable(foo ...) > target_link_libraries(foo bar bat) > include_directories(${bat_INCLUDE_DIRS} ${bar_INCLUDE_DIRS}) How do you propose to trigger this policy warning? At no one point while processing the above commands do we know whether the order changes. > I propose that > > target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar) > > should be allowed for an imported foo, but > > target_link_libraries(foo bar) > > remains not-allowed. Okay. The only purpose of it is to set properties while processing the debug/optimized keywords anyway. > As I introduced the INTERFACE_LINK_LIBRARIES property, I also introduced a > backward-compatibility feature to also read the old IMPORTED*_<CONFIG> > properties. I don't know enough about cmComputeLinkDepends to know if that's > ok. I don't think we should honor both properties at once. If the new name is set the old names should be ignored (perhaps with a warning if an old name is set too). A common use of LINK_INTERFACE_LIBRARIES is to be empty so this does not look correct: - if(!explicitLibraries && + if(explicitLibraries.empty() && > I asked before for more information about why direct depends are separated > from transitive ones. The reason seems to be related to ordering of the Yes. If you read and understand cmComputeLinkDepends in detail you will see there is no way to implement the current logic without keeping these separate. > depends when invoking the linker, which is relevant for static libraries > (but not shared libraries, right?). It's platform dependent IIRC. On some platforms order doesn't even matter among static libraries. On others order matters among both. > add_library(iface INTERFACE) > set_property(TARGET iface PROPERTY INTERFACE_LINK_LIBRARIES foo bar) > target_link_libraries(test_exe directdep1 iface directdep2) > > It is not really equivalent to this: > > target_link_libraries(test_exe directdep1 foo bar directdep2) > > But maybe it should be, or maybe I would want it to be? Maybe we can make it > possible to populate the non-INTERFACE LINK_LIBRARIES property on libraries > of type INTERFACE_LIBRARY to use the contents as direct depends of test_exe? Yes, interfaces should be flattened and replaced with their content. > I'm thinking of simply removing the memoization from cmTarget. Sure, they are only an optimization. Get things correct first and optimize later. > Because many boost libraries are header-only, my idea was that boost could > generate config and target files with content such as (pseudo dependencies): Yes. > add_library(boost::core INTERFACE IMPORTED) Side question: Does the "IMPORTED" status of an INTERFACE have any real meaning? It won't build anything in the project either way. > The problem is that boost dependencies are circular. > > One way to solve that would be to do something like this to make it non- > circular by using more internal-implementation-detail INTERFACE libraries: Good. It is a worthwhile example for your design whether it matches Boost's real dependencies or not. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers