Hi,
I'm again quite confused by how many things you now want to change compared
to what we were discussing before.
I'll try again to deal with it in b(y|i)tesize chunks.
Brad King wrote:
> For STATIC libraries we can
> define that the PUBLIC/PRIVATE/INTERFACE keys are ignored for
> linking and that it always populates both LINK_LIBRARIES
> LINK_INTERFACE_LIBRARIES.
That also means that one can do this:
add_library(libstatic STATIC ${srcs})
set_property(TARGET libstatic APPEND PROPERTY LINK_LIBRARIES foo)
# Warning: foo is not in the 'link interface' of libstatic.
It's quite a footgun. The existing semantic in CMake is 'for static
libraries, the link implementation is the link interface'.
I don't see the reason to change that semantic. Exporting the link
implementation as the link interface is not that complicated. I'd also worry
that there are other code-complications of trying to treat the link
implementation as the link interface if it does not come from the property,
and not otherwise.
I'd rather not change it. Why do you think it's important to try to change?
You wrote that it allows projects to 'deal with the link interface for all
targets the same way'. Can you post some code showing that benefit?
Thanks,
Steve.
--
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
