Hi,
On Saturday 29 December 2012, Stephen Kelly wrote:
Stephen Kelly wrote:
I'd like to defer the details of the
porcelain API for now and focus instead on the plumbing API and
implementation.
I have several quirks with the new command proposal, The new command can be
emulated with my
Stephen Kelly wrote:
I'd like to defer the details of the
porcelain API for now and focus instead on the plumbing API and
implementation.
I have several quirks with the new command proposal, The new command can be
emulated with my branch and this macro:
include(CMakeParseArguments)
On 12/21/2012 7:18 PM, Stephen Kelly wrote:
I don't think all the information is available from either side of the
debate on new-command vs use-tll. I'd like to defer the details of the
porcelain API for now and focus instead on the plumbing API and
implementation.
We will use the new
Brad King wrote:
On 12/18/2012 11:09 AM, Stephen Kelly wrote:
At generate time that property
will be used to accumulate values from INTERFACE_-like properties on
the named interfaces and append them to LINK_LIBRARIES, etc.
You wrote before that you don't propose using properties and
On 12/21/2012 01:08 PM, Stephen Kelly wrote:
If the target_use_interfaces command did not manipulate a USE_INTERFACES
property, but instead manipulated the mulitple INTERFACE_* properties in-
place (not appending) as my branch already does, it would be more clear.
I added a patch to my
On 12/18/2012 12:00 PM, Stephen Kelly wrote:
3. There is no change in behavior for existing use cases because the
new behavior comes only from new interfaces.
A new command and INTERFACE_LINK_LIBRARIES would have the same effect.
But, maybe a property which is only responsible for
Hi,
Brad King wrote:
I'll defer my thoughts on details of defining and exporting each
part of the interface for a future message after we've discussed
the overall approach.
I think it would be more helpful to understanding your proposal if you
detail those now instead.
So far I don't
Brad King wrote:
On 12/18/2012 10:38 AM, Stephen Kelly wrote:
Brad King wrote:
I'll defer my thoughts on details of defining and exporting each
part of the interface for a future message after we've discussed
the overall approach.
I think it would be more helpful to understanding your
On 12/18/2012 11:09 AM, Stephen Kelly wrote:
At generate time that property
will be used to accumulate values from INTERFACE_-like properties on
the named interfaces and append them to LINK_LIBRARIES, etc.
You wrote before that you don't propose using properties and generator
expressions:
On Tuesday 18 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
This would have the same effect, but people could simply hide the
USE_INTERFACES keyword in a variable:
set(Foo_LIBRARIES USE_INTERFACES Foo::FooLib)
and then it's again hidden:
target_link_libraries(hello
Alexander Neundorf wrote:
On Tuesday 18 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
This would have the same effect, but people could simply hide the
USE_INTERFACES keyword in a variable:
set(Foo_LIBRARIES USE_INTERFACES Foo::FooLib)
and then it's again hidden:
Brad King wrote:
This can all be done inside C++ structures rather than with
properties and generator expressions because it is only done during
generation.
That is the kind of thing I'm confused about. I don't see what value the
USE_INTERFACES property adds.
1. It puts the transitivity
On 12/12/2012 05:32 PM, David Cole wrote:
I strongly agree with Alex here.
Mysteriously changing the target_link_libraries implementation to
automatically do a bunch of stuff BY DEFAULT that it didn't used
to do violates the principle of least surprise big time.
Yes. Also I think some of
On Tuesday 11 December 2012, Stephen Kelly wrote:
Brad King wrote:
On 12/07/2012 06:10 AM, Stephen Kelly wrote:
Stephen Kelly wrote:
I haven't tried to analyse how much of the complexity is due to whether
target_use_targets or target_link_libraries is used. I think the harder
parts of
On 2012-12-11 08:35, Brad King wrote:
Another idea is to simply not allow both commands to be used on a given
target. Since the new command does not yet exist this cannot break any
existing projects. One must either specify everything by the new command
or everything by the old command.
How
2012/12/7 Stephen Kelly steve...@gmail.com
Stephen Kelly wrote:
I haven't tried to analyse how much of the complexity is due to whether
target_use_targets or target_link_libraries is used. I think the harder
parts of this topic so far have been related to exports. Like I said
though, I
Stephen Kelly wrote:
I haven't tried to analyse how much of the complexity is due to whether
target_use_targets or target_link_libraries is used. I think the harder
parts of this topic so far have been related to exports. Like I said
though, I haven't analysed how much of the exports
Hi,
I haven't followed the long thread between Brad and Stephen about importing
and exporting targets closely...
So, if I understand correctly, in the future the following cmake code
find_package(Foo)
add_executable(hello main.cpp)
target_link_libraries(hello ${Foo_LIBRARIES})
may also set
On Thursday 06 December 2012, Alexander Neundorf wrote:
...
I'd much prefer the following:
find_package(Foo NO_MODULE)
add_executable(hello main.cpp)
target_use_targets(hello Foo::FooLibrary)
which could even warn if a used library doesn't have include directory
properties set, etc.
Alexander Neundorf wrote:
Hi,
I haven't followed the long thread between Brad and Stephen about
importing and exporting targets closely...
So, if I understand correctly, in the future the following cmake code
find_package(Foo)
add_executable(hello main.cpp)
On Thu, Dec 6, 2012 at 3:37 PM, Stephen Kelly steve...@gmail.com wrote:
Alexander Neundorf wrote:
Hi,
I haven't followed the long thread between Brad and Stephen about
importing and exporting targets closely...
So, if I understand correctly, in the future the following cmake code
David Cole wrote:
On Thu, Dec 6, 2012 at 3:37 PM, Stephen Kelly
steve...@gmail.com wrote:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5111
I'm not sure what has changed since then.
What's changed since then is that we've seen how much change is needed for
22 matches
Mail list logo
