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
