Steve,
I think we're pretty close to agreement here!
On 05/30/2013 05:31 AM, Stephen Kelly wrote:
>> This will give projects a choice on whether they want to populate the
>> old properties explicitly or ask CMake to do it for them.
>
> Rather than offer so much choice for something which is pure backwards-
> compatibility (and therefore obsolete from the start), I'd prefer to offer
> only one way - user specified old properties.
Okay. This capability is only needed when a package requires a new CMake
itself but wants to support consumers with older CMake versions. I expect
this is not such an important use case. Let's go with the user-specified
old properties for optional export when the policy is NEW, as you propose.
> This seems very similar to the proposal I made ('I'd propose deprecating
> with a policy the signature...') that you vetoed. Is it just a refinement of
> what I proposed?
[snip]
> Yes, I think this is also what I proposed.
Yes, it is fair to call my proposal a refinement of yours. I read yours
to mean disallowing the old signature altogether. Mine is to disallow use
of old and new signatures together. That way the historical behavior will
continue to work without any warnings or errors but projects can choose to
use the new signature exclusively to get preferred behavior.
> Although I still propose deprecating LINK_PUBLIC/LINK_PRIVATE for
> PUBLIC/PRIVATE for consistency with the new commands.
This is fine, but I'd rather not produce any warnings for the LINK_
versions and just allow projects to use either. We can recommend the
latter in documentation.
One thing I left out of my last response was the behavior for STATIC
libraries. Here is what I said in the older thread:
On 12/22/2012 10:22 AM, Brad King wrote:
> For STATIC libraries the target_use_interfaces command
> PRIVATE/INTERFACE keywords still make sense because there could
> be different -I/-D for the implementation versus the interface.
> Only linking must be PUBLIC always. 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. Note that for STATIC libraries the
> LINK_LIBRARIES property will not be used for anything except
> build-order dependencies. Unlike the old LINK_INTERFACE_LIBRARIES
> the new INTERFACE_LINK_LIBRARIES will be used for static libs too.
> That way projects can deal with the link interface for all targets
> in the same way.
We need to update this for the lack of tui(). Whatever behavior we
define for STATIC libraries needs to make sense when used like this:
add_library(foo foo.c) # SHARED or STATIC based on BUILD_SHARED_LIBS
target_link_libraries(foo PUBLIC a PRIVATE b INTERFACE c)
I wonder if we can distinguish PUBLIC/PRIVATE/INTERFACE for STATIC
for application of usage requirements. The requirement to link
dependents to a static library's dependencies is an implementation
detail for linking only. Therefore we do not need to propagate the
other usage requirements (defines, includes) for private dependencies
of a static library. I think we can populate the LINK_LIBRARIES and
INTERFACE_LINK_LIBRARIES for static libraries the same as shared, and
just teach the link logic to use LINK_LIBRARIES for transitive *link*
behavior of static libraries but not for other usage requirements.
-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
