Brad King wrote:
> On 12/10/2012 09:52 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>
>>> IIRC the topic that added dependent export support was only
>>> finished for the install(EXPORT) command and not for export().
>>> It added a test for the install case mixing namespaces:
>>>
>>> http://cma
On 12/10/2012 09:52 AM, Stephen Kelly wrote:
> Brad King wrote:
>
>> IIRC the topic that added dependent export support was only
>> finished for the install(EXPORT) command and not for export().
>> It added a test for the install case mixing namespaces:
>>
>> http://cmake.org/gitweb?p=cmake.git;a
Brad King wrote:
> IIRC the topic that added dependent export support was only
> finished for the install(EXPORT) command and not for export().
> It added a test for the install case mixing namespaces:
>
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=955b9662
>
> It appears to work.
Yes
On 12/09/2012 08:48 AM, Stephen Kelly wrote:
> Brad King wrote:
>> Okay. Please add discussion there about the changes intended to be made
>> in the add-INTERFACE_LINK_LIBRARIES topic. We need to cover code examples
>> for existing behavior for all target and export/import types and how they
>> w
Brad King wrote:
> On 12/06/2012 05:04 PM, Stephen Kelly wrote:
>> I'd prefer the wiki. I think it would make sense to use/update/add a
>> design section to:
>>
>>
http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements
>>
>> or we could create a new page otherwise. It is ver
On 12/06/2012 05:00 PM, Stephen Kelly wrote:
> Currently it doesn't seem to work. Using current master with this:
>
> add_library(picon SHARED libone.cpp)
> add_library(picoff SHARED libtwo.cpp)
> target_link_libraries(picoff picon)
>
> export(TARGETS
>picon
>NAMESPACE foo_
>FILE
On 12/06/2012 05:04 PM, Stephen Kelly wrote:
> I'd prefer the wiki. I think it would make sense to use/update/add a design
> section to:
>
> http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements
>
> or we could create a new page otherwise. It is version controlled etc.
Okay
Brad King wrote:
>> Brad King wrote:
>>> How can we ever stop exporting the old interface when it comes from the
>>> link implementation?
>
> Now even projects that have never touched LINK_INTERFACE_LIBRARIES will
> have to be fixed to manually set it to a copy of the link implementation
> in ord
Stephen Kelly wrote:
>>
>> In the "Allow target_link_libraries with IMPORTED targets."
>> commit message, it says "This requires policy CMP0019 to be NEW".
>> However, I don't see any checks enforcing that or documentation.
>
> That may be a left-over from a previous version of the patch.
>
Tha
Brad King wrote:
> I'm picturing this as just a simple reStructuredText document in a branch
> of your repo. If anyone (like Alex) wants to join the discussion there
> will be one place to look for the current status.
I don't like the idea of using a branch in a repo. It would require checking
Brad King wrote:
> On 12/06/2012 03:53 PM, Stephen Kelly wrote:
>> Brad King wrote:
>>> How can we ever stop exporting the old interface when it comes from the
>>> link implementation?
>>
>> The approach I was thinking was to deal with it the same way we deal with
>> LINK_PUBLIC and LINK_PRIVATE
On 12/06/2012 03:53 PM, Stephen Kelly wrote:
> Brad King wrote:
>> How can we ever stop exporting the old interface when it comes from the
>> link implementation?
>
> The approach I was thinking was to deal with it the same way we deal with
> LINK_PUBLIC and LINK_PRIVATE - Make it depend on the p
On 12/06/2012 03:55 PM, Stephen Kelly wrote:
> Brad King wrote:
>> Let's keep the proposed changes in your Gitorious clone at
>>
>> https://gitorious.org/~steveire/cmake/steveires-cmake
>>
>> for now. If I need to push commits I'll publish them somewhere similar.
>
> So what are the next steps?
Brad King wrote:
> On 12/06/2012 08:08 AM, Stephen Kelly wrote:
>> There is another twist in the tail here. The existing topic on next is
>> not taking account of the case where the link implementation is the link
>> interface when exporting.
>
> After considering this issue and the concerns Alex
Brad King wrote:
> On 12/06/2012 08:08 AM, Stephen Kelly wrote:
>> There is another twist in the tail here. The existing topic on next is
>> not taking account of the case where the link implementation is the link
>> interface when exporting.
>
> Yes, of course :(
>
> How can we ever stop export
On 12/06/2012 08:08 AM, Stephen Kelly wrote:
> There is another twist in the tail here. The existing topic on next is not
> taking account of the case where the link implementation is the link
> interface when exporting.
After considering this issue and the concerns Alex raised in the new
"Setti
On 12/06/2012 08:08 AM, Stephen Kelly wrote:
> There is another twist in the tail here. The existing topic on next is not
> taking account of the case where the link implementation is the link
> interface when exporting.
Yes, of course :(
How can we ever stop exporting the old interface when it
Brad King wrote:
> Anyway, I think once the LINK_PUBLIC part of the policy is worked
> out then I'll perform one final review pass through the topic.
> I'd also like to have the CMP0019 test added to it covering the
> current form of the policy (since it's changed since you wrote the
> test before
Brad King wrote:
> On 12/03/2012 11:23 AM, Stephen Kelly wrote:
>> If the policy is NEW and I export a static library, then
>> only IMPORTED_LINK_INTERFACE_LIBRARIES(_) will be on the
>> generated IMPORTED targets (as is my understanding - I have not tried
>> this).
>
> Correct, but please test i
On 12/03/2012 11:23 AM, Stephen Kelly wrote:
> If the policy is NEW and I export a static library, then
> only IMPORTED_LINK_INTERFACE_LIBRARIES(_) will be on the generated
> IMPORTED targets (as is my understanding - I have not tried this).
Correct, but please test if you have a chance. Also,
Brad King wrote:
> On 12/03/2012 10:06 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> The CONFIG_DEBUG property complements the "debug" keyword in tll().
>>> That's all it does, and it exactly matches the behavior we need in
>>> the motivating case. Something like $ may
>>> be useful but that c
On 12/03/2012 10:06 AM, Stephen Kelly wrote:
> Brad King wrote:
>> The CONFIG_DEBUG property complements the "debug" keyword in tll().
>> That's all it does, and it exactly matches the behavior we need in
>> the motivating case. Something like $ may
>> be useful but that can be added in the future
Brad King wrote:
> On 12/02/2012 04:35 AM, Stephen Kelly wrote:
>
>> Simliarly with the link-type keywords in the INTERFACE_LINK_LIBRARIES
>> property check, you might not like the message string that I used in the
>> error, you might ask me to change it, etc and we'll end up doing more
>> trips
On 12/02/2012 04:35 AM, Stephen Kelly wrote:
> I would really prefer if you would commit this directly to the branch
> instead, as you had written it locally already. There is no point in having
> to go through me. The branch can be our collaboration point. Me copying your
> patch and pushing it
Brad King wrote:
> And another. Here is new documentation I've written based on this
> discussion.
Done now.
I would really prefer if you would commit this directly to the branch
instead, as you had written it locally already. There is no point in having
to go through me. The branch can be our
On 11/30/2012 02:46 PM, Brad King wrote:
> On 11/30/2012 01:59 PM, Brad King wrote:
>> Perhaps the simplest solution is to add a new generator expression
>> such as $ that evaluates to 1 or 0 depending on
>> whether the configuration is considered a debug config.
>
> Another detail. The cmTargetC
On 11/30/2012 01:59 PM, Brad King wrote:
> I noticed that generatorIface hard-codes "$>"
> instead of looking up the list of DEBUG configs:
>
> // Get the list of configurations considered to be DEBUG.
> std::vector const& debugConfigs =
> this->Makefile->GetCMakeInstance()->GetDebugConfig
On 11/30/2012 01:31 PM, Stephen Kelly wrote:
> Brad King wrote:
>>
>> Right. The tll() call specifies the "link implementation" which then
>> becomes the link interface when exported.
>
> Yes, and later when my other topic is merged that will work for the 'new'
> link interface for static librar
Brad King wrote:
>>
>> causes the IMPORTED_LINK_INTERFACE_LIBRARIES_ of the IMPORTED
>> picoff to contain picon with CMake 2.8.9, because
>> cmExportFileGenerator::SetImportDetailProperties populates that with the
>> link implementation in the case of static libraries.
>
> Right. The tll() call
On 11/30/2012 11:58 AM, Stephen Kelly wrote:
> add_library(picon STATIC libone.cpp)
> add_library(picoff STATIC libtwo.cpp)
> target_link_libraries(picoff LINK_INTERFACE_LIBRARIES picon)
>
> get_target_property(_res picoff LINK_INTERFACE_LIBRARIES)
> message("PROP : ${_res}")
>
> outputs this wit
On 11/30/2012 12:36 PM, Stephen Kelly wrote:
> Stephen Kelly wrote:
>> Currently, in the add-INTERFACE_LINK_LIBRARIES-property branch, the
>> INTERFACE_LINK_LIBRARIES property is read for static libraries if the
>> policy is new,
>
> I've changed that now in the branch. Effort is made to not popul
Stephen Kelly wrote:
> Currently, in the add-INTERFACE_LINK_LIBRARIES-property branch, the
> INTERFACE_LINK_LIBRARIES property is read for static libraries if the
> policy is new,
I've changed that now in the branch. Effort is made to not populate the
property, and even if it does get populated,
Brad King wrote:
> On 11/30/2012 11:50 AM, Stephen Kelly wrote:
>> That test, as it currently appears in next, does not create any static
>> libraries. Is it possible that build only broke because of the reverts
>> and because continuous builds are not clean builds?
>
> It was failing before the
Brad King wrote:
> Well, we want generator expressions in tll() to work for static
> libraries. Therefore we must populate INTERFACE_LINK_LIBRARIES
> for IMPORTED targets generated from static libraries. However,
> in the producing (exporting) project it does not make sense to
> have separate LIN
On 11/30/2012 11:50 AM, Stephen Kelly wrote:
> That test, as it currently appears in next, does not create any static
> libraries. Is it possible that build only broke because of the reverts and
> because continuous builds are not clean builds?
It was failing before the reverts. My comment abou
Stephen Kelly wrote:
> Brad King wrote:
>
>> On 11/30/2012 11:07 AM, Stephen Kelly wrote:
>>> Brad King wrote:
Please restart your INTERFACE_LINK_LIBRARIES topic on master
>>>
>>> Thanks, I've done that now.
>>
>> The target_link_libraries test fails:
>>
>> http://open.cdash.org/testDeta
Brad King wrote:
> On 11/30/2012 11:07 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> Please restart your INTERFACE_LINK_LIBRARIES topic on master
>>
>> Thanks, I've done that now.
>
> The target_link_libraries test fails:
>
> http://open.cdash.org/testDetails.php?test=168404487&build=269136
On 11/30/2012 11:07 AM, Stephen Kelly wrote:
> Brad King wrote:
>> Please restart your INTERFACE_LINK_LIBRARIES topic on master
>
> Thanks, I've done that now.
The target_link_libraries test fails:
http://open.cdash.org/testDetails.php?test=168404487&build=2691368
...
CMake Warning (dev) in C
Brad King wrote:
> On 11/30/2012 10:27 AM, Brad King wrote:
>> I'll revert the entire block of topics for you. After that you can
>> start from scratch by rebasing the INTERFACE_LINK_LIBRARIES changes
>> by themselves on master. I'll respond again when it's ready.
>
> Done. I removed all the t
On 11/30/2012 10:27 AM, Brad King wrote:
> I'll revert the entire block of topics for you. After that you can
> start from scratch by rebasing the INTERFACE_LINK_LIBRARIES changes
> by themselves on master. I'll respond again when it's ready.
Done. I removed all the topics from the stage too.
Brad King wrote:
>> Does the static library stuff need
>> to be accounted for in some way already in that branch?
>
> Well, we want generator expressions in tll() to work for static
> libraries. Therefore we must populate INTERFACE_LINK_LIBRARIES
> for IMPORTED targets generated from static libra
On 11/30/2012 10:10 AM, Stephen Kelly wrote:
> Brad King wrote:
>> You could add one commit at the end of each of those to revert them
>> from next until we've worked out this part. Then go back and rebase
>> them on the result.
>
> I tried doing that, but they're all hopelessly tangled. Do you t
Brad King wrote:
> On 11/30/2012 09:34 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> Feel free to rewrite the staged topics as much as you want to keep
>>> things tested as they evolve from this discussion.
>>
>> Modulo dependent branches which are already merged to next and causing
>> problem
On 11/30/2012 09:31 AM, Stephen Kelly wrote:
>> IIRC we planned to expose the generator expressions in the link
>> interface so they would be ultimately evaluated in the context of
>> the consuming target.
>
> Yes, I put that in a separate patch, because it has its own complexity and I
> wanted t
On 11/30/2012 09:34 AM, Stephen Kelly wrote:
> Brad King wrote:
>> Feel free to rewrite the staged topics as much as you want to keep things
>> tested as they evolve from this discussion.
>
> Modulo dependent branches which are already merged to next and causing
> problems for further merging, ye
Brad King wrote:
> On 11/29/2012 04:35 PM, Stephen Kelly wrote:
>> I've pushed add-INTERFACE_LINK_LIBRARIES-property to my gitorious clone.
>> Is that what you meant?
>
> I linked the exact commit I meant in 'next'. I'll look at this one now.
>
>> Is IMPORTED_LINK_DEPENDENT_LIBRARIES different
Brad King wrote:
> On 11/30/2012 08:39 AM, Brad King wrote:
>> On 11/29/2012 04:35 PM, Stephen Kelly wrote:
>>> I've pushed add-INTERFACE_LINK_LIBRARIES-property to my gitorious clone.
>>
>> I'll look at this one now.
>
> This still appears to use the policy in ComputeImportInfo.
> In our curren
On 11/30/2012 08:39 AM, Brad King wrote:
> On 11/29/2012 04:35 PM, Stephen Kelly wrote:
>> I've pushed add-INTERFACE_LINK_LIBRARIES-property to my gitorious clone.
>
> I'll look at this one now.
This still appears to use the policy in ComputeImportInfo.
In our current design CMake >= 2.8.11 shoul
On 11/29/2012 04:35 PM, Stephen Kelly wrote:
> I've pushed add-INTERFACE_LINK_LIBRARIES-property to my gitorious clone. Is
> that what you meant?
I linked the exact commit I meant in 'next'. I'll look at this one now.
> Is IMPORTED_LINK_DEPENDENT_LIBRARIES different from the others? It doesn't
[Sorry if you get this twice. I'm not getting it echo'd back through mail or
gmane]
Stephen Kelly wrote:
> I've pushed add-INTERFACE_LINK_LIBRARIES-property to my gitorious clone.
> Is that what you meant?
I've now also pushed a no-export-old-link-interface branch, which I can
also push to ne
Stephen Kelly wrote:
> I've pushed add-INTERFACE_LINK_LIBRARIES-property to my gitorious clone.
> Is that what you meant?
I've now also pushed a no-export-old-link-interface branch, which I can also
push later today.
Thanks,
--
Powered by www.kitware.com
Visit other Kitware open-source proje
Brad King wrote:
> On 11/28/2012 05:15 PM, Stephen Kelly wrote:
>>> I think we can drop the consumer-side policy completely. Consumers will
>>> load imported targets with the old and/or new interfaces specified as
>>> chosen by the
>>> producing project.
>>>
>>> CMake < 2.8.11 will just use the o
On 11/28/2012 05:15 PM, Stephen Kelly wrote:
>> I think we can drop the consumer-side policy completely. Consumers will
>> load imported targets with the old and/or new interfaces specified as
>> chosen by the
>> producing project.
>>
>> CMake < 2.8.11 will just use the old interface. CMake
>>> =
On 11/29/2012 02:24 PM, Stephen Kelly wrote:
> And for the usecase of 'foo doesn't link to bar, but if using foo you need
> bar', is
>
> target_link_libraries(foo INTERFACE bar)
Yes. This will populate only the new name.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source pr
Brad King wrote:
> Perhaps part of the NEW
> behavior of CMP0019 can be that LINK_PUBLIC/LINK_PRIVATE do
> not populate the old interface. Anyone that wants to provide
> both interfaces can set the policy to NEW and then set the
> old interface explicitly.
And for the usecase of 'foo doesn't link
On 11/28/2012 05:15 PM, Stephen Kelly wrote:
> I guess the old interface is not exported if it is unset, so if the producer
> stops populating the old interface, they stop exporting it too. The problem
> is we'd need to provide a way for them to not populate the old interface.
Yes.
> Having the
Brad King wrote:
> Hi Stephen,
>
> I've looked through the add-INTERFACE_LINK_LIBRARIES-property topic.
> Unless I'm misunderstanding something I think we can simplify CMP0019
> quite a bit. What made it complicated in earlier discussions was a desire
> to generate and export INTERFACE_LINK_LIBR
Hi Stephen,
I've looked through the add-INTERFACE_LINK_LIBRARIES-property topic. Unless
I'm misunderstanding something I think we can simplify CMP0019 quite a bit.
What made it complicated in earlier discussions was a desire to generate and
export INTERFACE_LINK_LIBRARIES even from projects that
58 matches
Mail list logo
