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:
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
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
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
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):
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
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:
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
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
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)
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
Hi,
Last year we discussed the addition of a INTERFACE_LINK_LIBRARIES property
to replace the (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_CONFIG)? 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
45 matches
Mail list logo
