Brad King wrote:
> 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.
Agreed.
> 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.
Ah, that's what I missed from your email, and the critical difference.
Indeed, what I proposed was to disallow the old signature altogether with
the policy.
I'm not convinced that a policy to disallow the old and new signatures
together is actually better though. It preserves the historical behavior
even if the policy is NEW, and will be a bit confusing for anyone attempting
to use a new signature with a LHS target, especially if the new signature is
already in use elsewhere in the project or file ('It works with foo, why
doesn't it work with bar in the same file?!?'). Seen the other way, for a
target which uses the new signature, someone reading internet/docs/tutorials
and seeing the old signature will not be able to use it, if the policy is
NEW.
For anyone hitting issues like those, it will make sense at that point to
port everything to the new signature anyway for maintenance
> 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.
In spite of the above, I can agree to that in the interest of moving along
and getting some new consistent signatures in place.
>> 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.
Ok. Let's see how that fits together with the rest of the issues.
> 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.
Something like this will probably be possible. I'll have a closer look at
the implementation later.
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
