The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13833
==
Reported By:Matt Arsenault
Assigned To:
Shlomi Fish wrote:
> Hi all,
>
> following a discussion we had on ##llvm on irc.oftc.net (the main LLVM
> channel, because LLVM+clang can be built using CMake), I've been wondering
> if you would like someone (like me) to implement an interactive debugger
> (or debugging "mode") for cmake invocat
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13832
==
Reported By:Amine Khaldi
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13831
==
Reported By:Amine Khaldi
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13830
==
Reported By:Amine Khaldi
Assigned To:
Brad King wrote:
> On 01/03/2013 12:12 PM, Stephen Kelly wrote:
>> I was not talking about the patch. I was talking about the -Wundef issue
>> and the kwsys issue that it exposes:
>>
>>
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5665/focus=5672
>
> http://review.source.ki
Brad King wrote:
>> I'd like to focus first on the on those commits and get them ready for
>> review. They are in the interface-includes-defines branch in my clone.
>
> Here are some comments:
>
> * Please add a test for the TARGET_NAME non-literal error cases, both in
> direct use of the expre
On 12/29/2012 05:10 AM, Stephen Kelly wrote:
> Brad King wrote:
>
>> 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.
>
> We spent some time figuring out how to not e
On 12/29/2012 05:14 AM, Stephen Kelly wrote:
> Brad King wrote:
>
>> When the property is not set (internally it is WARN) then tll()
>
> s/property/policy/ ?
Yes.
> s/internally/initially/ ?
No, I was referring to cmPolicies::WARN.
>> will populate both the old and new properties. ComputeLin
On 12/26/2012 06:04 AM, Stephen Kelly wrote:
> Brad King wrote:
>> 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.
>
> That also means that one can do this:
>
> a
On 01/03/2013 03:32 PM, Stephen Kelly wrote:
> While the porcelain API for setting includes and defines is somewhat
> controversial, the plumbing is not, as far as I can tell. I previously wrote
> that I'd like to get all of the INTERFACE_* related commits in together, but
> I don't think that m
Hi there,
While the porcelain API for setting includes and defines is somewhat
controversial, the plumbing is not, as far as I can tell. I previously wrote
that I'd like to get all of the INTERFACE_* related commits in together, but
I don't think that matters so much really. I'd prefer to get
On 01/03/2013 12:12 PM, Stephen Kelly wrote:
> I was not talking about the patch. I was talking about the -Wundef issue and
> the kwsys issue that it exposes:
>
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5665/focus=5672
http://review.source.kitware.com/9187
-Brad
--
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13829
==
Reported By:Alessio M.
Assigned To:
David Cole wrote:
> That has now been merged to master of kwsys:
> http://review.source.kitware.com/#/c/9043/
>
> It will appear in CMake soon.
>
I guess I should have quoted more context.
I was not talking about the patch. I was talking about the -Wundef issue and
the kwsys issue that it ex
That has now been merged to master of kwsys:
http://review.source.kitware.com/#/c/9043/
It will appear in CMake soon.
On Thu, Jan 3, 2013 at 11:35 AM, Stephen Kelly wrote:
> Stephen Kelly writes:
>
> > Is this email enough of a report about that, or do you want a tracker
> entry?
>
> Any res
Stephen Kelly writes:
> Is this email enough of a report about that, or do you want a tracker entry?
Any response to this?
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-top
On 01/03/2013 10:26 AM, Stephen Kelly wrote:
> Currently the new Qt4Targets test I wrote is running on many linux and mac,
> but is failing on the SLED LSB platforms.
>
> http://open.cdash.org/testSummary.php?project=1&name=Qt4Targets&date=2013-01-03
Relevant output for reference:
Linking CXX
Hi there,
Currently the new Qt4Targets test I wrote is running on many linux and mac,
but is failing on the SLED LSB platforms.
http://open.cdash.org/testSummary.php?project=1&name=Qt4Targets&date=2013-01-03
The test is essentially testing that the LINK_INTERFACE_LIBRARIES property
on the Qt4
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13828
==
Reported By:Jeremy Cook
Assigned To:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13827
==
Reported By:Martin Müllenhaupt
Assigned To:
21 matches
Mail list logo