Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > A few other tests have had the same problem. I think I've fixed them all now. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 06/27/2013 06:42 PM, Stephen Kelly wrote: >> Brad King wrote: >>> >>> The current topic looks pretty good and I will perform more >>> testing soon. >> >> Sounds good! I'll test it more too. > > The documentation looks good except for a couple missing spaces: > > "compatibility with downstream users of CMake versions older than > 2.8.12." > +"The target_link_libraries command will no longer populate the " > ... > +"property for in-build targets, and ignore the old properties > matching" > +"(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_)?.", Fixed now. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/27/2013 06:42 PM, Stephen Kelly wrote: > Brad King wrote: >> >> The current topic looks pretty good and I will perform more >> testing soon. > > Sounds good! I'll test it more too. The documentation looks good except for a couple missing spaces: "compatibility with downstream users of CMake versions older than 2.8.12." +"The target_link_libraries command will no longer populate the " ... +"property for in-build targets, and ignore the old properties matching" +"(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_)?.", 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/27/2013 06:42 PM, Stephen Kelly wrote: > Brad King wrote: >> The current topic looks pretty good and I will perform more >> testing soon. > > Sounds good! I'll test it more too. Thanks for cleaning up the initial dashboard trouble. There is one lingering problem in VS 6: http://open.cdash.org/testDetails.php?test=193818480&build=2953898 bar.obj : error LNK2001: unresolved external symbol "int __cdecl bang(void)" (?bang@@YAHXZ) ...\Tests\InterfaceLinkLibraries\Release/bar_shared.dll : fatal error LNK1120: 1 unresolved externals I don't think there is anything wrong with your code. The problem is that VS 6 does not support per-target objects so the re-use of some of the source files in multiple targets results in only one object file so the different preprocessing behavior you expect does not work. A few other tests have had the same problem. What we do to work around it is add sources like foo_vs6_1.cpp and foo_vs6_2.cpp that contain just #include "foo.cpp" and use them in place of foo.cpp in each target for the VS 6 gen. This ensures a separate object file name for each target in the test. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: >> I believe >> >> tll(tgt LINK_PRIVATE a LINK_PUBLIC b LINK_PRIVATE c) >> >> is valid today. I can't think of a reason to want that > > We considered such cases way back when first discussing that interface. > The use case is that there is an ordered implementation dependency on > "a;b;c" but only "b" should be in the link interface. True. Added a unit test and pushed again to my clone. I'll wait until INTERFACE_LINK_LIBRARIES-prop is in master before merging it to next. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/28/2013 08:42 AM, Stephen Kelly wrote:
> However, it should be only:
>
> target_link_libraries( ...
>[ ...] ...])
Yes.
> I can change that so that all of the following are valid:
>
> tll(tgt PRIVATE a PUBLIC b INTERFACE c)
> tll(tgt INTERFACE c PRIVATE a PUBLIC b)
> tll(tgt INTERFACE c PUBLIC b PRIVATE a)
> tll(tgt INTERFACE c PUBLIC b PRIVATE a PUBLIC d INTERFACE e)
Yes. I think that will be the simplest to use. Please be
sure that empty library lists in cases like
tll(tgt PRIVATE a PUBLIC INTERFACE c)
work because they could come from
tll(tgt PRIVATE a PUBLIC ${list_of_libs_maybe_empty} INTERFACE c)
> I believe
>
> tll(tgt LINK_PRIVATE a LINK_PUBLIC b LINK_PRIVATE c)
>
> is valid today. I can't think of a reason to want that
We considered such cases way back when first discussing that interface.
The use case is that there is an ordered implementation dependency on
"a;b;c" but only "b" should be in the link interface.
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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > So, if the first argument after the lhs is "LINK_PUBLIC" > or "LINK_PRIVATE" then it is the existing signature, and if > it is "PUBLIC" or "PRIVATE" or "INTERFACE" then it is the > "new" signature, right? Right. That's almost what is in my tll-new-signatures branch: target_link_libraries( INTERFACE ...) target_link_libraries( ... [ ...] ...]) However, it should be only: target_link_libraries( ... [ ...] ...]) right? I can change that so that all of the following are valid: tll(tgt PRIVATE a PUBLIC b INTERFACE c) tll(tgt INTERFACE c PRIVATE a PUBLIC b) tll(tgt INTERFACE c PUBLIC b PRIVATE a) tll(tgt INTERFACE c PUBLIC b PRIVATE a PUBLIC d INTERFACE e) I believe tll(tgt LINK_PRIVATE a LINK_PUBLIC b LINK_PRIVATE c) is valid today. I can't think of a reason to want that, but I guess we shouldn't change it. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/28/2013 06:02 AM, Stephen Kelly wrote: > Is it really worthwhile to introduce both INTERFACE and LINK_INTERFACE? No, I forgot that "LINK_INTERFACE" does not exist. It is fine to just add "INTERFACE". > * LINK_PUBLIC is treated as an alias for PUBLIC > * LINK_PRIVATE is treated as an alias for PRIVATE Yes, though see response below about mixing. > * LINK_INTERFACE_LIBRARIES is *not* treated as an ALIAS for INTERFACE Correct. This one is different because it is a command mode, not a keyword that can appear anywhere among other libraries. > That would mean mixtures like this would be allowed: > > target_link_libraries(lhs LINK_PUBLIC a PRIVATE b) > > Should they be? I was thinking that at the time I sent the grandparent message but now that I see an example spelled out I agree it looks nicer to make them exclusive. That will also be easier to document because the list of signatures will not need something like "" in it. So, if the first argument after the lhs is "LINK_PUBLIC" or "LINK_PRIVATE" then it is the existing signature, and if it is "PUBLIC" or "PRIVATE" or "INTERFACE" then it is the "new" signature, right? 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > Okay, I think we've had some confusion due to differing assumptions > about the meaning of "old" and "new" tll signatures. Let me be more > explicit. For the signature policy, there are two groups of signatures: > > * Group A (what I called "old" signatures): > > target_link_libraries(lhs a b c) > target_link_libraries(lhs LINK_INTERFACE_LIBRARIES a b c) > > * Group B (what I called "new" signatures): > > target_link_libraries(lhs LINK_PUBLIC a LINK_PRIVATE b LINK_INTERFACE c) > target_link_libraries(lhs PUBLIC a PRIVATE b INTERFACE c) Is it really worthwhile to introduce both INTERFACE and LINK_INTERFACE? > The semantics of the two group B signatures are *identical*. There > is absolutely ZERO distinction between PUBLIC and LINK_PUBLIC. Ok. So, * LINK_PUBLIC is treated as an alias for PUBLIC * LINK_PRIVATE is treated as an alias for PRIVATE * LINK_INTERFACE_LIBRARIES is *not* treated as an ALIAS for INTERFACE Correct? > I expected to see things like > > - else if(args[i] == "LINK_PUBLIC") > + else if(args[i] == "PUBLIC" || args[i] == "LINK_PUBLIC") That would mean mixtures like this would be allowed: target_link_libraries(lhs LINK_PUBLIC a PRIVATE b) Should they be? > Now, the signature policy should have the following behavior: > > * OLD: Group A *and* group B can be used for one lhs > * NEW: Group A *xor* group B can be used for one lhs Right. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 6/27/2013 10:18 AM, Stephen Kelly wrote: >> I went with the option of setting the INTERFACE_LINK_LIBRARIES >> unconditionally in tll. > > That's fine with me. It keeps things simpler internally. > Strictly speaking we should make it conditional on the > policy not being set to OLD, but it doesn't matter much. > > The current topic looks pretty good and I will perform more > testing soon. Sounds good! I'll test it more too. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 6/27/2013 10:18 AM, Stephen Kelly wrote: > I went with the option of setting the INTERFACE_LINK_LIBRARIES > unconditionally in tll. That's fine with me. It keeps things simpler internally. Strictly speaking we should make it conditional on the policy not being set to OLD, but it doesn't matter much. The current topic looks pretty good and I will perform more testing soon. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 06/27/2013 05:28 AM, Stephen Kelly wrote: >> Please post a snippet of cmake code showing the problems you are seeing >> so that I can easily understand them. > > Consider this code using CMake 2.8.11: > > cmake_minimum_required(VERSION 2.8.11) > #... > add_library(foo SHARED foo.c) > target_link_libraries(foo LINK_PUBLIC a) > set_property(TARGET foo APPEND PROPERTY LINK_INTERFACE_LIBRARIES b) > > If someone were to change the first line to require 2.8.12 then > suddenly the link interface will drop "b" silently. Thanks. That was the description I was looking for. > > With my suggestion then tll will also populate INTERFACE_LINK_LIBRARIES > if the policy is not set (or a C++-only proxy). From that the existing > comparison of old and new interface properties will work. > I went with the option of setting the INTERFACE_LINK_LIBRARIES unconditionally in tll. I also added a test for the case above, and added a FATAL_ERROR in the export file if required, and pushed it all to my clone again. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/27/2013 05:28 AM, Stephen Kelly wrote: > Please post a snippet of cmake code showing the problems you are seeing so > that I can easily understand them. Consider this code using CMake 2.8.11: cmake_minimum_required(VERSION 2.8.11) #... add_library(foo SHARED foo.c) target_link_libraries(foo LINK_PUBLIC a) set_property(TARGET foo APPEND PROPERTY LINK_INTERFACE_LIBRARIES b) If someone were to change the first line to require 2.8.12 then suddenly the link interface will drop "b" silently. With my suggestion then tll will also populate INTERFACE_LINK_LIBRARIES if the policy is not set (or a C++-only proxy). From that the existing comparison of old and new interface properties will work. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/27/2013 03:35 AM, Stephen Kelly wrote: > Brad King wrote: >> On 6/26/2013 12:24 PM, Stephen Kelly wrote: >> I think the generated targets file will need to bump its >> minimum required version of CMake if the policy is NEW >> and the compatibility export option is not used. Otherwise >> consuming projects running older CMake versions will silently >> get through the CMake step and fail at build time. > > Yes, something has to be done to fix that. I would add a check on the cmake > version with a FATAL_ERROR, like in the Qt 5 config files. It looks like > bumping the CMAKE_IMPORT_FILE_VERSION alone wouldn't have any effect because > there is no other code checking it, so that would have to be added. It seems > easier to me and no worse to add a FATAL_ERROR? Yes, a version check with a fatal error would work. The CMAKE_IMPORT_FILE_VERSION is for forward compatibility. I do not know if we'll ever use it but I wanted to add it at the beginning just in case. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > The build of the project itself will not change, and even > external consumers will behave the same if they are built > with the same version of CMake. It's confusing to me that so much of what you wrote is stuff I'm obviously already familiar with, having implemented a few policies already. I assume you're just trying to be crystal-clear, but for me it's just more confusing. I understand the intention of policies. I think the misunderstanding we're having here is that I don't know what scenario you are trying to point out which should be emitting a warning in my INTERFACE_LINK_LIBRARIES-prop branch. Or what scenario is emitting a policy warning in my branch although it shouldn't. Snippets of 'problematic' cmake code would be much more helpful than prose to understand that. > I think the case where existing code would produce different > behavior if the policy were set to NEW without other changes > is when the project sets the old LINK_INTERFACE_LIBRARIES > properties directly instead of asking tll() to do it. I think this is what we've been discussing from the beginning, is it not? That has been unit tested in my branch for a long time. It emits a warning. Maybe you missed it? Or maybe this is more 'reinforcement' and being crystal-clear? Or maybe there's a subtlety in what you wrote above that I am missing which makes it describe something different from my unit test? > * WARN (not set): Same as OLD, but tll additionally populates > a C++-only copy of what *would* have been put in the newer > INTERFACE_LINK_LIBRARIES property. Then cmTarget computes > what *would* have been the new-style link interface and > compares it to the actual link interface computed from the > OLD behavior. This comparison will indicate whether the > behavior would change and can produce the warning if so. > (We could also consider setting INTERFACE_LINK_LIBRARIES > instead of using a C++-only copy under the expectation that > the project does not know about the property anyway.) This seems to be the only different suggestion to what is already in my branch. Before implementing that though, I would like to know why the change is needed and what cmake code is 'problematic' in my branch, but would be 'fixed' by implementing the above. That way I can add a unit test for it. > With this approach there shouldn't be any policy warnings > generated for code that uses only tll(). As far as I know, this is already the case in my branch. Please post a snippet of cmake code showing the problems you are seeing so that I can easily understand them. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 6/26/2013 12:24 PM, Stephen Kelly wrote: >> EXPORT_LINK_INTERFACE_LIBRARIES option > > I think the generated targets file will need to bump its > minimum required version of CMake if the policy is NEW > and the compatibility export option is not used. Otherwise > consuming projects running older CMake versions will silently > get through the CMake step and fail at build time. Yes, something has to be done to fix that. I would add a check on the cmake version with a FATAL_ERROR, like in the Qt 5 config files. It looks like bumping the CMAKE_IMPORT_FILE_VERSION alone wouldn't have any effect because there is no other code checking it, so that would have to be added. It seems easier to me and no worse to add a FATAL_ERROR? 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 6/26/2013 12:24 PM, Stephen Kelly wrote: > EXPORT_LINK_INTERFACE_LIBRARIES option I think the generated targets file will need to bump its minimum required version of CMake if the policy is NEW and the compatibility export option is not used. Otherwise consuming projects running older CMake versions will silently get through the CMake step and fail at build time. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Steve, In this topic we need to distinguish between two types of warnings: * Policy Warnings: Generated using GetPolicyWarning. These should appear only when the policy is not set (WARN), and should be triggered in cases that involve only old-style code that if left unmodified would behave differently when the policy is set to NEW. * Other warnings. These can come from unexpected uses of the new and/or old properties regardless of the policy (non-)setting. On 6/26/2013 12:24 PM, Stephen Kelly wrote: >> It can't be triggered by "new-style" code because the whole >> point of policy warnings is to trigger for old code not yet >> aware of the policy and the preferred new behavior. > > I'm not sure what in particular you're referring to here. Maybe it's the > export case I described above? By "new-style" code I mean code written to use properties introduced in the same version of CMake that introduces the policy. If such code appears in the project then clearly the developers are aware of the new features and presumably the existence of the policy. The purpose of a policy is to preserve behavior for existing project releases that pre-date developers' awareness of the policy and its behavior change. The warning generated when the policy is not set (WARN) needs to be of the form: "CMake now prefers to do something different with this existing code but for compatibility we are doing the old thing. Please update the project to be aware of the preferred behavior and tell us which one to do." In this case old code calling only tll and install(EXPORT) and not setting any properties explicitly will behave the same whether the policy is set to OLD or NEW, except that the properties exposed to external consumers will change. The build of the project itself will not change, and even external consumers will behave the same if they are built with the same version of CMake. I think the case where existing code would produce different behavior if the policy were set to NEW without other changes is when the project sets the old LINK_INTERFACE_LIBRARIES properties directly instead of asking tll() to do it. We may have to re-think the internal handling of the policy WARN behavior in order to identify cases that should trigger a GetPolicyWarning message. Perhaps the following will work: * NEW: tll sets INTERFACE_LINK_LIBRARIES and cmTarget computes the link interface using it. * OLD: tll sets LINK_INTERFACE_LIBRARIES(_) and cmTarget computes the link interface using them. * WARN (not set): Same as OLD, but tll additionally populates a C++-only copy of what *would* have been put in the newer INTERFACE_LINK_LIBRARIES property. Then cmTarget computes what *would* have been the new-style link interface and compares it to the actual link interface computed from the OLD behavior. This comparison will indicate whether the behavior would change and can produce the warning if so. (We could also consider setting INTERFACE_LINK_LIBRARIES instead of using a C++-only copy under the expectation that the project does not know about the property anyway.) With this approach there shouldn't be any policy warnings generated for code that uses only tll(). This is good because such projects do not actually need any modification for the policy's NEW behavior to do the right thing. For code that uses set_property to set LINK_INTERFACE_LIBRARIES(_) directly the warning may trigger, which is good because such projects will need modification for the policy's NEW behavior to do the right thing. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote:
> On 06/07/2013 09:36 AM, Brad King wrote:
>> Great. One more part to think about is how the warning can work
>> for the interface policy.
> * OLD behavior uses the old properties for everything
> (tll sets them, cmTarget reads them)
> * NEW behavior uses the new property for everything
> (tll sets it, cmTarget reads it)
> When the policy is not set we will use the old behavior, but
> when would we ever warn to ask developers to set the policy?
The current implementation in my clone emits a warning only if the old and
new properties are both set for one target and contain different values.
What other situations should be warned about?
In the new GetTransitivePropertyLinkLibraries() method I have code like
+ if (this->GetPolicyStatusCMP0022() == cmPolicies::WARN
+ || this->GetPolicyStatusCMP0022() == cmPolicies::OLD)
+{
i.e., don't actually emit a warning from this method if the policy is WARN.
This snippet is called only when evaluating generator expressions to get
transitive property values from the link interface. I could check if the new
property is populated there, and emit a warning something along the lines
that 'you are using the old and new properties on the same target', which is
the warning they'd see anyway from cmTarget::ComputeLinkInterface.
Similarly, I emit a warning if the CMP0022 policy is set to NEW, but the
EXPORT_LINK_INTERFACE_LIBRARIES option to export() was not used and the old
properties are populated. This can only happen if the developer incorrectly
reacts to the policy by setting the policy to NEW but not using
EXPORT_LINK_INTERFACE_LIBRARIES and not removing code which causes the old
properties to be populated. So, it's not like a regular 'policy warning'
which is to warn about existing code usage to migrate away from, but still
an author warning that they haven't handled the policy correctly yet
(Actually it's a FATAL_ERROR, not a warning).
> It can't be triggered by "new-style" code because the whole
> point of policy warnings is to trigger for old code not yet
> aware of the policy and the preferred new behavior.
I'm not sure what in particular you're referring to here. Maybe it's the
export case I described above?
> Perhaps we can warn whenever someone sets the old property
> explicitly through set_property or set_target_properties
> such that it would not be mapped by the policy's changes
> to tll behavior. Other ideas?
Such set_property or set_target_properties calls will result in a warning
from cmTarget::ComputeLinkInterface, so I don't understand why another is
needed?
>> We could also warn when someone sets the new-style properties
>> but does not set the policy to NEW.
>
> To clarify, this would be a general warning and not tied to
> complaining when the policy is not set. Obviously such code
> is aware of the new properties already.
Same as above, I'm not sure why another warning would be needed, or I don't
understand what you are suggesting.
I've re-pushed the INTERFACE_LINK_LIBRARIES-prop branch to my clone with a
rebase.
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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/07/2013 09:36 AM, Brad King wrote: > Great. One more part to think about is how the warning can work > for the interface policy. In what I proposed: > > * OLD behavior uses the old properties for everything > (tll sets them, cmTarget reads them) > * NEW behavior uses the new property for everything > (tll sets it, cmTarget reads it) > > Note that in the NEW behavior, even the old-style tll > LINK_INTERFACE_LIBRARIES signature will set the new property. > > When the policy is not set we will use the old behavior, but > when would we ever warn to ask developers to set the policy? > It can't be triggered by "new-style" code because the whole > point of policy warnings is to trigger for old code not yet > aware of the policy and the preferred new behavior. > > Perhaps we can warn whenever someone sets the old property > explicitly through set_property or set_target_properties > such that it would not be mapped by the policy's changes > to tll behavior. Other ideas? I'm still not sure what is best to do with the above. > We could also warn when someone sets the new-style properties > but does not set the policy to NEW. To clarify, this would be a general warning and not tied to complaining when the policy is not set. Obviously such code is aware of the new properties already. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/26/2013 03:52 AM, Stephen Kelly wrote: > * I think I confused you by working on both the tll signature and the new > property in the same branch in my clone. I split out the tll-new-signatures > topic from INTERFACE_LINK_LIBRARIES-prop topic. Yes, there was some mixing of the commits for the two orthogonal changes. I also added to the confusion by over-using the terms "old" and "new" in my reviews instead of spelling out what I meant. > Option A) Drop the insistence that tll-new-signatures is merged first. > > I can then address your feedback on INTERFACE_LINK_LIBRARIES-prop > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6767/focus=7122 > > and get it merged, then follow up with tll-new-signatures. Okay, let's go with this option. You'll have to start by rebasing the topic since commit bb4260c9 was already put in next and reverted. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Stephen Kelly wrote: > Anyway, we can let this one sleep for a bit and come back to it all later. Returning to this topic: * I think I confused you by working on both the tll signature and the new property in the same branch in my clone. I split out the tll-new-signatures topic from INTERFACE_LINK_LIBRARIES-prop topic. * The INTERFACE_LINK_LIBRARIES-prop topic is important. Several other topics depend on it, including introduction of the INTERFACE_LIBRARY. * The tll-new-signatures topic is unimportant. Nothing depends on it. It has caused more friction and churn in the discussion so far, and I am certain there is still more to discuss/figure out before merging it. My interest is in the INTERFACE_LINK_LIBRARIES-prop topic. * You insist that tll-new-signatures be merged before INTERFACE_LINK_LIBRARIES-prop. * There is no need or actual value in doing that re-ordering. There is only busy-work of renumbering the policies which is very demotivational. To move beyond this situation: Option A) Drop the insistence that tll-new-signatures is merged first. I can then address your feedback on INTERFACE_LINK_LIBRARIES-prop http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6767/focus=7122 and get it merged, then follow up with tll-new-signatures. Pros: * Can start now * Can get the important branch in first Cons: * Things don't get merged in the order you want Option B) Pull and rewrite Pull my tll-new-signatures branch and renumber/reorder/rewrite at will and push the result where I can get it. When tll-new-signatures is in, I can address the feedback on INTERFACE_LINK_LIBRARIES-prop. Pros: * Things get merged in the order you want * I don't do the re-numbering * You get to write tll-new-signatures as you want it to be. Cons: * Delays INTERFACE_LINK_LIBRARIES-prop until tll-new-signatures is in. Option C) Continue to do nothing. Pros: * Time can be helpful. Cons: * Nothing continues to happen 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > Currently the INTERFACE_LINK_LIBRARIES-prop topic has > gone through a few iterations due to confusing the two. I just don't agree with that :). There has not been anything unusual about the topic compared to any other topic. The (simpler) topmost commit has been split/revised a few times, but that was never merged to next. The rest of the commits were just updated as normal in response to the dashboard, and as far as I know are merge ready modulo small issues. Anyway, we can let this one sleep for a bit and come back to it all 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/07/2013 09:20 AM, Stephen Kelly wrote: > Brad King wrote: >> Don't you mean LINK_INTERFACE_LIBRARIES there? > > Yep, I fixed it and pushed it to my clone. Great. One more part to think about is how the warning can work for the interface policy. In what I proposed: * OLD behavior uses the old properties for everything (tll sets them, cmTarget reads them) * NEW behavior uses the new property for everything (tll sets it, cmTarget reads it) Note that in the NEW behavior, even the old-style tll LINK_INTERFACE_LIBRARIES signature will set the new property. When the policy is not set we will use the old behavior, but when would we ever warn to ask developers to set the policy? It can't be triggered by "new-style" code because the whole point of policy warnings is to trigger for old code not yet aware of the policy and the preferred new behavior. Perhaps we can warn whenever someone sets the old property explicitly through set_property or set_target_properties such that it would not be mapped by the policy's changes to tll behavior. Other ideas? We could also warn when someone sets the new-style properties but does not set the policy to NEW. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/07/2013 09:22 AM, Stephen Kelly wrote: > Brad King wrote: > >> Let me request this a third time and more explicitly: please revert >> the INTERFACE_LINK_LIBRARIES-prop topic from next and drop it until >> the signature policy is ready. Introduce the signature policy as >> CMP0022. After we've settled that topic and it is clean on the >> dashboard then start again on INTERFACE_LINK_LIBRARIES. > > I've reverted it from next. > > Given the orthogonality, I don't understand why you want the signature > change in first. Renumbering the policies doesn't seem worthwhile. It is a less-invasive change that also introduces the final tll siganture. With those tll updates out of the way we will be able to concentrate more on defining the behavior for the interface policy. Currently the INTERFACE_LINK_LIBRARIES-prop topic has gone through a few iterations due to confusing the two. Let's get the simpler one done first. Also, the signature policy will be useful on its own if for some reason INTERFACE_LINK_LIBRARIES does not get finished for a while. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > Let me request this a third time and more explicitly: please revert > the INTERFACE_LINK_LIBRARIES-prop topic from next and drop it until > the signature policy is ready. Introduce the signature policy as > CMP0022. After we've settled that topic and it is clean on the > dashboard then start again on INTERFACE_LINK_LIBRARIES. I've reverted it from next. Given the orthogonality, I don't understand why you want the signature change in first. Renumbering the policies doesn't seem worthwhile. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 06/06/2013 07:27 PM, Stephen Kelly wrote: >> Ok. I've added a commit which I think completes the policy CMP0022 and >> the addition of the INTERFACE_LINK_LIBRARIES property. > > One quick comment on the export change: > > + e << "Target \"" << target->GetName() << "\" has policy CMP0022 " > +"enabled, but also has old-style INTERFACE_LINK_LIBRARIES " > +"properties populated, but it was exported without the " > > Don't you mean LINK_INTERFACE_LIBRARIES there? > Yep, I fixed it and pushed it to my clone. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/06/2013 07:27 PM, Stephen Kelly wrote: > Ok. I've added a commit which I think completes the policy CMP0022 and the > addition of the INTERFACE_LINK_LIBRARIES property. One quick comment on the export change: + e << "Target \"" << target->GetName() << "\" has policy CMP0022 " +"enabled, but also has old-style INTERFACE_LINK_LIBRARIES " +"properties populated, but it was exported without the " Don't you mean LINK_INTERFACE_LIBRARIES there? -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/07/2013 04:01 AM, Stephen Kelly wrote: > I've pushed the commit to my clone again. It is not as simple as above > because of how the uses of the signatures are recorded, and because I > disallow the use of debug/optimized/general with the new signatures. > > Other than that, I think it's as described. +"Similar target_link_libraries signatures can not be mixed.", Okay, I think we've had some confusion due to differing assumptions about the meaning of "old" and "new" tll signatures. Let me be more explicit. For the signature policy, there are two groups of signatures: * Group A (what I called "old" signatures): target_link_libraries(lhs a b c) target_link_libraries(lhs LINK_INTERFACE_LIBRARIES a b c) * Group B (what I called "new" signatures): target_link_libraries(lhs LINK_PUBLIC a LINK_PRIVATE b LINK_INTERFACE c) target_link_libraries(lhs PUBLIC a PRIVATE b INTERFACE c) The semantics of the two group B signatures are *identical*. There is absolutely ZERO distinction between PUBLIC and LINK_PUBLIC. All signatures in both groups continue to support debug/optimized keywords because their use is pervasive in find modules. Now, the signature policy should have the following behavior: * OLD: Group A *and* group B can be used for one lhs * NEW: Group A *xor* group B can be used for one lhs Let me request this a third time and more explicitly: please revert the INTERFACE_LINK_LIBRARIES-prop topic from next and drop it until the signature policy is ready. Introduce the signature policy as CMP0022. After we've settled that topic and it is clean on the dashboard then start again on INTERFACE_LINK_LIBRARIES. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > I expected to see things like > > - else if(args[i] == "LINK_PUBLIC") > + else if(args[i] == "PUBLIC" || args[i] == "LINK_PUBLIC") I've pushed the commit to my clone again. It is not as simple as above because of how the uses of the signatures are recorded, and because I disallow the use of debug/optimized/general with the new signatures. Other than that, I think it's as described. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 06/06/2013 02:18 PM, Stephen Kelly wrote: >> Brad King wrote: >>> But those are incomplete. The policy CMP0022 you added should also >>> affect the implementation of tll to choose which interface properties >>> to populate. >> >> I thought that's what we have a second policy (CMP0023) for? Isn't that >> what we discussed? > > Read my last review comments again. > > The policies are orthogonal but both change tll: Ok. I've added a commit which I think completes the policy CMP0022 and the addition of the INTERFACE_LINK_LIBRARIES property. I did have a different idea of the scope of the two policies compared to your idea. I think I understand how that came about. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/06/2013 02:18 PM, Stephen Kelly wrote: > Brad King wrote: >> But those are incomplete. The policy CMP0022 you added should also >> affect the implementation of tll to choose which interface properties >> to populate. > > I thought that's what we have a second policy (CMP0023) for? Isn't that what > we discussed? Read my last review comments again. The policies are orthogonal but both change tll: * The signature policy affects allowed combinations of old and new signature calls (where "new" includes LINK_(PUBLIC|PRIVATE|INTERFACE)). The OLD behavior allows old AND new signature calls on the same target. The NEW behavior allows old XOR new signature calls on the same target. It has no effect on link interface properties, set or get. * The interface policy affects which properties define the link interface. In OLD behavior tll populates the old properties and CMake uses them. In NEW behavior tll populates the new property and CMake uses it. It has no effect on allowed tll signatures. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 06/06/2013 01:33 PM, Stephen Kelly wrote: >> Brad King wrote: >> >>> The tll signature commit does not do what I had in mind. >> >> Ok, I'll have another look later. Meanwhile, I've merged the first >> orthogonal commits to next to see what the dashboard makes of it. > > But those are incomplete. The policy CMP0022 you added should also > affect the implementation of tll to choose which interface properties > to populate. I thought that's what we have a second policy (CMP0023) for? Isn't that what we discussed? 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/06/2013 01:33 PM, Stephen Kelly wrote: > Brad King wrote: > >> The tll signature commit does not do what I had in mind. > > Ok, I'll have another look later. Meanwhile, I've merged the first > orthogonal commits to next to see what the dashboard makes of it. But those are incomplete. The policy CMP0022 you added should also affect the implementation of tll to choose which interface properties to populate. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > The tll signature commit does not do what I had in mind. Ok, I'll have another look later. Meanwhile, I've merged the first orthogonal commits to next to see what the dashboard makes of it. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/06/2013 07:40 AM, Stephen Kelly wrote: > Ok, I've updated the topic in my clone. I think the only remaining issue is > new tests for tll(). Thanks. Here are some comments: +"Enable use of the INTERFACE_LINK_LIBRARIES property.", How about "INTERFACE_LINK_LIBRARIES defines the link interface.". The wording needs to make sense when viewed in the future when everyone is used to this behavior. It should not sound like this is an option one must "enable". +"The OLD behavior for this policy is to use the INTERFACE_LINK_LIBRARIES " +"property only for IMPORTED targets, and ignore it otherwise. " +"The NEW behavior for this policy is to use the INTERFACE_LINK_LIBRARIES " +"property for all targets, and ignore the old properties matching" +"(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_)?.", The policy should not affect imported targets at all. Even mentioning "(IMPORTED_)?" in the documentation may be confusing. We should just document that the policy is only for in-project targets. Then over in the property documentation for the old and new properties document when one overrides the other. The wording of the INTERFACE_LINK_LIBRARIES documentation looks too much like LINK_INTERFACE_LIBRARIES and talks about "replacing the default". That's not quite how the new property works, especially after the tll signature policy. Please revise this. + "The EXPORT_LINK_INTERFACE_LIBRARIES keyword, if present, causes the " + "contents of the LINK_INTERFACE_LIBRARIES properties to be exported, " + "even if policy CMP0022 is NEW. " s/even if/when/ since the keyword cannot be used without the policy. Also use the wording "properties matching ..." to refer to the properties more precisely. +"with downstream users of older cmake versions." We should specify the CMake versions: < 2.8.12. The tll signature commit does not do what I had in mind. The signature policy should not affect availability of signatures, only the combinations allowed. I expected to see things like - else if(args[i] == "LINK_PUBLIC") + else if(args[i] == "PUBLIC" || args[i] == "LINK_PUBLIC") for the option aliases. Also the signature policy should not affect whether tll populates the old or new link interface properties. Only the other policy should do that. I also expected to see modification of tll as part of introduction of the link interface policy. Like I said before, these policies are orthogonal. The signature policy should be completely implementable before introduction of the new interface properties. I think your topic will be simpler to implement and review if you do the signature policy first to the point that we can merge it to master and then base the INTERFACE_LINK_LIBRARIES part on that. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > Once we have agreement on that then PUBLIC|PRIVATE|INTERFACE will be > aliases. Ok, I've updated the topic in my clone. I think the only remaining issue is new tests for tll(). 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/05/2013 10:02 AM, Stephen Kelly wrote: > I think a clean break is a better idea. Then why not have a new command for linking? Your proposal makes *all* the old and new tll() signatures completely separate and not usable on a single target. It is essentially a new command with the same name. (I'm not really proposing a new command name here, just pointing this out for sake of argument.) My signature policy proposal was intended to eliminate existing confusion caused by using the ancient signatures in combination with LINK_(PUBLIC|PRIVATE|INTERFACE) signatures. This signature policy is independent of INTERFACE_LINK_LIBRARIES or its policy. Consider implementing the signature policy first as a separate change and then base the INTERFACE_LINK_LIBRARIES topic on it. The two changes are orthogonal but together accomplish the goal of an empty link interface for shared libraries by default. Supporting EXPORT_LINK_INTERFACE_LIBRARIES will require code changes for projects. The signature policy won't allow them to use the tll LINK_INTERFACE_LIBRARIES signature in combination with the new signatures anyway, so they will have to use set_property to populate the old LINK_INTERFACE_LIBRARIES properties to work with EXPORT_LINK_INTERFACE_LIBRARIES. We've already agreed that the need for a project to do this is fairly rare and obscure. Please use an approach that pretends the LINK_ options will be the only names in the "new" signatures. Once we have agreement on that then PUBLIC|PRIVATE|INTERFACE will be aliases. That is what we discussed earlier in this thread. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
I've force pushed to my clone again. I haven't added tests yet, and I've only been smoke testing as I go along. Brad King wrote: > In the tll() signature policy I think LINK_PUBLIC/LINK_PRIVATE should > be an alias for PUBLIC/PRIVATE. The "old" signatures are only the > one without any keywords plus the one with LINK_INTERFACE_LIBRARIES. > The "new" signatures are the (LINK_)?(PUBLIC|PRIVATE|INTERFACE) mode. > That is why we need a policy to make the old and new sigs exclusive. Currently in my patch, the LINK_PUBLIC and LINK_PRIVATE are considered old signatures. That's easy to document and keeps most relevant existing documentation together without changing it. As a consequence of being part of the old signature, the use of LINK_PRIVATE determines whether the old LINK_INTERFACE_LIBRARIES is populated with an empty value. The use of the new signature with PRIVATE determines whether to populate the new INTERFACE_LINK_LIBRARIES property. It might be possible to control whether the INTERFACE_LINK_LIBRARIES is populated with an empty value determined by the policy alone (and make LINK_PRIVATE an alias for PRIVATE as you suggest), but for anyone transitioning (and using EXPORT_LINK_INTERFACE_LIBRARIES) it is more things to think about, it is more nuances to document in the policy and in the tll() documentation and it is more complex to implement. Similarly, for static libraries, we want to populate the INTERFACE_LINK_LIBRARIES with different stuff (genexes) when using the new signature. Again, that could be controlled by the policy alone, but for the same complexity , documentation and nuance arguments above, I don't think it should be. I think a clean break is a better idea. > Instead we should wrap the "private" link-only dependencies in an > expression because they are the ones that do not belong in the > interface. Perhaps use $ or $ > where ... can even be a list to avoid verbosity for adjacent > link-only entries. I've implemented LINK_ONLY now. The implementation of the genex supports lists, but the implementation of target_link_libraries would need to be refactored to emit groups instead of single libraries in order to take advantage of it. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 06/04/2013 11:44 AM, Stephen Kelly wrote: > I've pushed my current work to my clone in the INTERFACE_LINK_LIBRARIES-prop > topic. It's not yet complete, but I think it has almost all elements of the > solution. +"CMake 2.8.11 consumed the 'link interface' of a target from properties " s/consumed/constructed/ + if(te->Target->GetPolicyStatusCMP0022() != cmPolicies::NEW) This should be "not OLD and not WARN" because in the future it may be REQUIRE_ALWAYS or REQUIRE_IF_USED which are new behavior. The export() command will also need the EXPORT_LINK_INTERFACE_LIBRARIES option. In the tll() signature policy I think LINK_PUBLIC/LINK_PRIVATE should be an alias for PUBLIC/PRIVATE. The "old" signatures are only the one without any keywords plus the one with LINK_INTERFACE_LIBRARIES. The "new" signatures are the (LINK_)?(PUBLIC|PRIVATE|INTERFACE) mode. That is why we need a policy to make the old and new sigs exclusive. > An issue with static libraries arises when exporting, as we only export the > INTERFACE_LINK_LIBRARIES, but we want to communicate both link dependencies > and usage dependencies through it. I left a comment in one of the commits > proposing a genex-based solution similar to the INSTALL_INTERFACE genex. I see that here: + // Perhaps we should populate it with a generator expression similar to + // INSTALL_INTERFACE and BUILD_INTERFACE expressions? As the order is + // relevant, the entries which are for usage requirements only can + // be wrapped in $ Instead we should wrap the "private" link-only dependencies in an expression because they are the ones that do not belong in the interface. Perhaps use $ or $ where ... can even be a list to avoid verbosity for adjacent link-only entries. -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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Hi, I've pushed my current work to my clone in the INTERFACE_LINK_LIBRARIES-prop topic. It's not yet complete, but I think it has almost all elements of the solution. Brad King wrote: >>> 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. >> >> Something like this will probably be possible. I'll have a closer look at >> the implementation later. An issue with static libraries arises when exporting, as we only export the INTERFACE_LINK_LIBRARIES, but we want to communicate both link dependencies and usage dependencies through it. I left a comment in one of the commits proposing a genex-based solution similar to the INSTALL_INTERFACE genex. 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 05/30/2013 10:50 AM, Stephen Kelly wrote:
> 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?!?').
* The error (or warning when policy is not set) message should list all
call sites along with which signature they use and explain that they
need to be made consistent. Currently the tll() docs for the old
signature warn that the new signature can "break" the public interface.
* The signature policy setting should be queried at each call site rather
than recorded when the target is created.
> For anyone hitting issues like those, it will make sense at that point to
> port everything to the new signature anyway for maintenance
Yes, and the signature policy's message can help with doing that.
> In spite of the above, I can agree to that in the interest of moving along
> and getting some new consistent signatures in place.
That is my goal also. My "signature policy" proposal is motivated by:
(1) The old signatures make sense on their own.
Lots of projects use them. They are not "wrong".
(2) The new signatures make sense on their own.
They have better shared library interface defaults.
(3) Combinations of old and new signatures produce confusing results
Policies are intended for use when a new behavior is clearly superior
to the old behavior. Both (1) and (2) are fine individually, even with
INTERFACE_LINK_LIBRARIES. It is the behavior in (3) that is bad and
making old/new signatures exclusive is clearly superior.
>> 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.
>
> Something like this will probably be possible. I'll have a closer look at
> the implementation later.
Great, 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 05/10/2013 06:41 AM, Stephen Kelly wrote: >> * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5680 >> (New INTERFACE_LINK_LIBRARIES policy approach) > > I remember being quite happy with the proposal I made at the start of > that thread. Let's see if we can come up with something equivalent. > For reference, the key sections of my message were: > > On 12/22/2012 10:22 AM, Brad King wrote: >> First I'll define how the properties behave when building a target. >> I'll cover exporting below. >> >> In the OLD behavior the link interface is completely determined as >> it is in CMake 2.8.10 by the LINK_INTERFACE_LIBRARIES(_) >> properties. The target_link_libraries command will populate the >> properties as it does now and leave the new names untouched. >> >> In the NEW behavior the link interface is completely determined >> by the new INTERFACE_LINK_LIBRARIES property. All forms of tll() >> including its LINK_INTERFACE_LIBRARIES mode will populate only >> the new properties. The old property is completely ignored. Any thoughts on adding PUBLIC PRIVATE and INTERFACE keywords to tll for consistency with the other target_* commands? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6864/focus=6886 >> When the policy is not set (internally it is WARN) then tll() >> will populate both the old and new properties. ComputeLinkInterface >> will compute both the old and new style link interfaces, warn if >> they are different, and use the old one. Ok. > ... >> Now, on to exporting. Unlike the previous iteration the policy >> affects it too. >> >> When the policy is OLD/WARN we export only the old interface and >> not the new interface. >> >> When the policy is NEW we export only the new interface and not >> the old interface by default. We can have a new property to >> explicitly request that the old link interface properties be >> exported. We can either ask projects to set the old interface >> properties manually for export or try to compute the values from >> the new ones by pre-evaluating the generator expressions for >> each configuration. This will allow projects to support older >> CMake versions for their clients if they want to, but it will >> be an explicit decision. Yes. > Now, returning to your message: > > On 05/10/2013 06:41 AM, Stephen Kelly wrote: >> If the new property is introduced, the behavior would be: >> >> * If an in-buildsystem or IMPORTED target has the new property, it is >> used >> and the old properties are not used. > > For in-build targets this needs to depend on the policy setting as in my > quote above. The behavior of the project's build should not depend on > the version of CMake currently running, but rather the behavior intended > by the project author. The intention is implied by the policy setting > or lack of one. Right. > For IMPORTED targets I think your proposal is correct: use the new > property if it is set and otherwise use the old property. It is up to > the provider of the imported targets to specify the old and/or new > properties correctly to handle various CMake versions for consumers. Right. >> * When a target is install(EXPORT)ed, the new property will be exported. > > ...when the policy is NEW. When it is OLD/WARN we export only the old > properties. Ok. >> ** There needs to be a way to determine whether to additionally export >> the >>old properties. Even if the exporting target does not have the old >>properties set, we can still conditionally write the content of the >>new INTERFACE_LINK_LIBRARIES to IMPORTED_LINK_INTERFACE_LIBRARIES, as >>both now support generator expressions. This will allow exporting >>projects to maintain compatibility with downstreams using CMake 2.8.11 >>(or earlier if generator expressions are not used). > > Yes, and the install(EXPORT) option you proposed can work for that. > If possible I'd like to try to (partially) evaluate the $-type > expressions to set the old per-config properties. That will make it easy > for packages to support the old properties for CMake < 2.8.11. I'm still not a fan of partial evaluation like that. It would be complex and a source of bugs for little gain. >> ** If the old properties and the new property are set, we export them >>all. This will allow exporting projects to maintain compatibility with >>downstreams using CMake < 2.8.11. It is ok if the new >>INTERFACE_LINK_LIBRARIES and the old LINK_INTERFACE_LIBRARIES have >>differing content and no warning is issued. The new property may >>simply contain new genex-powered-convenience, similar to how QtCore >>now conveniently links to the qtmain.lib now on Windows. > > Perhaps whatever install(EXPORT) option exports the old properties can > also somehow indicate whether to use the project's settings for the old > properties or try to generate values automatically from the new ones. I'd prefer not to try to magically
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 05/10/2013 06:41 AM, Stephen Kelly wrote: > * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5680 > (New INTERFACE_LINK_LIBRARIES policy approach) I remember being quite happy with the proposal I made at the start of that thread. Let's see if we can come up with something equivalent. For reference, the key sections of my message were: On 12/22/2012 10:22 AM, Brad King wrote: > First I'll define how the properties behave when building a target. > I'll cover exporting below. > > In the OLD behavior the link interface is completely determined as > it is in CMake 2.8.10 by the LINK_INTERFACE_LIBRARIES(_) > properties. The target_link_libraries command will populate the > properties as it does now and leave the new names untouched. > > In the NEW behavior the link interface is completely determined > by the new INTERFACE_LINK_LIBRARIES property. All forms of tll() > including its LINK_INTERFACE_LIBRARIES mode will populate only > the new properties. The old property is completely ignored. > > When the property is not set (internally it is WARN) then tll() > will populate both the old and new properties. ComputeLinkInfo > will compute both the old and new style link interfaces, warn if > they are different, and use the old one. ... > Now, on to exporting. Unlike the previous iteration the policy > affects it too. > > When the policy is OLD/WARN we export only the old interface and > not the new interface. > > When the policy is NEW we export only the new interface and not > the old interface by default. We can have a new property to > explicitly request that the old link interface properties be > exported. We can either ask projects to set the old interface > properties manually for export or try to compute the values from > the new ones by pre-evaluating the generator expressions for > each configuration. This will allow projects to support older > CMake versions for their clients if they want to, but it will > be an explicit decision. Now, returning to your message: On 05/10/2013 06:41 AM, Stephen Kelly wrote: > If the new property is introduced, the behavior would be: > > * If an in-buildsystem or IMPORTED target has the new property, it is used > and the old properties are not used. For in-build targets this needs to depend on the policy setting as in my quote above. The behavior of the project's build should not depend on the version of CMake currently running, but rather the behavior intended by the project author. The intention is implied by the policy setting or lack of one. For IMPORTED targets I think your proposal is correct: use the new property if it is set and otherwise use the old property. It is up to the provider of the imported targets to specify the old and/or new properties correctly to handle various CMake versions for consumers. > * When a target is install(EXPORT)ed, the new property will be exported. ...when the policy is NEW. When it is OLD/WARN we export only the old properties. > ** There needs to be a way to determine whether to additionally export the >old properties. Even if the exporting target does not have the old >properties set, we can still conditionally write the content of the new >INTERFACE_LINK_LIBRARIES to IMPORTED_LINK_INTERFACE_LIBRARIES, as both >now support generator expressions. This will allow exporting projects to >maintain compatibility with downstreams using CMake 2.8.11 (or earlier if >generator expressions are not used). Yes, and the install(EXPORT) option you proposed can work for that. If possible I'd like to try to (partially) evaluate the $-type expressions to set the old per-config properties. That will make it easy for packages to support the old properties for CMake < 2.8.11. > ** If the old properties and the new property are set, we export them >all. This will allow exporting projects to maintain compatibility with >downstreams using CMake < 2.8.11. It is ok if the new >INTERFACE_LINK_LIBRARIES and the old LINK_INTERFACE_LIBRARIES have >differing content and no warning is issued. The new property may simply >contain new genex-powered-convenience, similar to how QtCore now >conveniently links to the qtmain.lib now on Windows. Perhaps whatever install(EXPORT) option exports the old properties can also somehow indicate whether to use the project's settings for the old properties or try to generate values automatically from the new ones. This will give projects a choice on whether they want to populate the old properties explicitly or ask CMake to do it for them. > * target_link_libraries signatures will populate the new > INTERFACE_LINK_LIBRARIES property. There will need to be a way to make it > additionally conditionally populate the old properties. See my proposed approach quoted above for this. > So, the primary thing to determine is whether to export the old properties, > which is related to whether they get populated by tll().
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Stephen Kelly wrote: > * When exporting, if 'the implementation is the interface' Oops, forgot to finish writing this. With the policy, the required tll signature, and new property, the implementation is never the interface for shared libraries. Static libraries are already handled by the existing code by populating the interface property with the evaluated libraries since commit 77d26467 (Allow generator expressions in LINK_INTERFACE_LIBRARIES., 2013-01-04). 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 05/06/2013 12:44 PM, Stephen Kelly wrote: >> I'm not sure what you mean by 'for now'? > > I meant we could drop it and move on but not rule out the possibility > of someday moving to it for consistency and (eventual) simplicity. > >> I'd prefer not to introduce INTERFACE_LIBRARY with support for the >> old-style interface if there will eventually be a new-style. > > Perhaps we can look at reviving it but we'll have to re-work the > policy to handle generator expressions in the old interface as > you pointed out. Can you please take a stab at proposing the > new form of the policy (in design only, no code yet). For reference, here's some old threads: * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5398 (Policy for INTERFACE_LINK_LIBRARIES) * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5526 (Setting include directories via target_link_libraries() ?) * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5680 (New INTERFACE_LINK_LIBRARIES policy approach) * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5734 (Interface includes and defines plumbing) * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5904 (Setting includes, defines and other usage requirements with one command) In summary, we spent some time discussing INTERFACE_LINK_LIBRARIES while at the same time discussing the tll-vs-new-command question and various options for how to implement the plumbing. Eventually, without fanfare and apparently without discussion on the mailing list, I abandonned that INTERFACE_LINK_LIBRARIES property in early January and added genex support to the properties matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_)? instead. The topic was merged in c0c8ef85fc8d65a47abfd293031bcde91e7ee930. This meant that the complexity of issues associated with introducing the new property were worked-around - namely which properties to install(EXPORT). The initial justification for replacing the old properties with the new one was so that targets would have property content like this using a uniform property name: LINK_LIBRARIES $ That became irrelevant long ago as it was based on my misunderstanding about how link lines are determined. Other justifications for the new property remain: * Name consistency with INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS * Not having a suffix, which is no longer needed because of genex support * Consistency of access to the link interface. For static imported targets, the old IMPORTED_LINK_INTERFACE_LIBRARIES property contains the link interface, but for non-imported static libraries the old LINK_INTERFACE_LIBRARIES does not. * We may in the future find a need and justification for a genex like $ which determines whether foo is linked. The i implementation of that genex would be a lot simpler if it needed to support only one property. This may be unlikely however. Currently properties like COMPATIBLE_INTERFACE_* solve similar problems that a $ would solve. * We can have empty INTERFACE_LINK_LIBRARIES on shared libraries by default. * ?? If the new property is introduced, the behavior would be: * If an in-buildsystem or IMPORTED target has the new property, it is used and the old properties are not used. * When a target is install(EXPORT)ed, the new property will be exported. ** There needs to be a way to determine whether to additionally export the old properties. Even if the exporting target does not have the old properties set, we can still conditionally write the content of the new INTERFACE_LINK_LIBRARIES to IMPORTED_LINK_INTERFACE_LIBRARIES, as both now support generator expressions. This will allow exporting projects to maintain compatibility with downstreams using CMake 2.8.11 (or earlier if generator expressions are not used). ** If the old properties and the new property are set, we export them all. This will allow exporting projects to maintain compatibility with downstreams using CMake < 2.8.11. It is ok if the new INTERFACE_LINK_LIBRARIES and the old LINK_INTERFACE_LIBRARIES have differing content and no warning is issued. The new property may simply contain new genex-powered-convenience, similar to how QtCore now conveniently links to the qtmain.lib now on Windows. * target_link_libraries signatures will populate the new INTERFACE_LINK_LIBRARIES property. There will need to be a way to make it additionally conditionally populate the old properties. There needs to be a final-migration-moment where projects no longer export targets with the old properties. * If the INTERFACE_LINK_LIBRARIES property is read on a static non-imported library, its LINK_LIBRARIES property is returned. * When exporting, if 'the implementation is the interface' So, the primary thing to determine is whether to export the old properties, which is related
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 05/06/2013 12:44 PM, Stephen Kelly wrote: > I'm not sure what you mean by 'for now'? I meant we could drop it and move on but not rule out the possibility of someday moving to it for consistency and (eventual) simplicity. > I'd prefer not to introduce INTERFACE_LIBRARY with support for the old-style > interface if there will eventually be a new-style. Perhaps we can look at reviving it but we'll have to re-work the policy to handle generator expressions in the old interface as you pointed out. Can you please take a stab at proposing the new form of the policy (in design only, no code yet). 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote: > On 05/03/2013 07:37 AM, Stephen Kelly wrote: >> Alternatively we could decide to finally drop the >> INTERFACE_LINK_LIBRARIES property. > > I think we can just drop it for now. I'm not sure what you mean by 'for now'? I'd prefer not to introduce INTERFACE_LIBRARY with support for the old-style interface if there will eventually be a new-style. Alternatively, we could agree not to introduce INTERFACE_LINK_LIBRARIES, live with the inconsistent naming and the IMPORTED_ prefix, and I can delete my branch for it (spring cleaning). 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
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
On 05/03/2013 07:37 AM, Stephen Kelly wrote: > Alternatively we could decide to finally drop the > INTERFACE_LINK_LIBRARIES property. I think we can just drop it for now. -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
[cmake-developers] INTERFACE_LINK_LIBRARIES property?
Hi, Last year we discussed the addition of a INTERFACE_LINK_LIBRARIES property to replace the (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_)? properties. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5398 After a lot of back-and-forth, I bypassed the issue of that property by adding generator expression support to the (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_)? properties instead. Part of the policy under discussion relied on an assumption that the LINK_LIBRARIES property does not contain generator expressions, but that assumption won't be true anymore after 2.8.11 is released. I think that related to the fact that if LINK_LIBRARIES contains generator expressions, and the link implementation is the link interface, then only the new INTERFACE_LINK_LIBRARIES should be populated and not the old interface properties (because they couldn't handle the genexes). So, if we still want to introduce INTERFACE_LINK_LIBRARIES, we may need to re-think that part. Alternatively we could decide to finally drop the INTERFACE_LINK_LIBRARIES property. If we do introduce it, I'd want to get it in before the INTERFACE_LIBRARY so that that target type only supports the new property. Comments? 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
