The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14209
==
Reported By:mwoehlke
Assigned To:
On 6/6/2013 9:44 PM, Alan W. Irwin wrote:
In this particular case I have specified gcc using
CMAKE_C_COMPILER. That bombs with the message
-- Check for working C compiler: z:/home/wine/newstart/MinGW-4.7.2/bin/gcc.exe
-- broken
Did you look in the CMakeError.log file to see why it fails?
-
Some problems were reported with the 2.8.11 release. Thanks to the
swift work of Brad King, Stephen Kelly, Rolf Eike Beer and Modestas
Vainius, those problems have been fixed. We've prepared a 2.8.11.1 bug
fix release to address those issues.
The change log page for this bug-fix only release is he
On 6/6/2013 9:44 PM, Alan W. Irwin wrote:
Assuming you confirm my finding that the "NMake Makefiles JOM" generator does
not currently work properly with the MinGW suite of compilers is
there some small change in language support that
would make that work?
I can confirm that I have never attempt
On Tue, 4 Jun 2013 13:45:34 -0400, Brad King said:
>> 'CTestTestFdSetSize' is superficially happening in an OS header's macro:
>>
>> static __inline int
>> __darwin_fd_isset(int _n, const struct fd_set *_p)
>> {
>> return (_p->fds_bits[_n/__DARWIN_NFDBITS] & (1<<(_n %
>> __DARWIN_NFDBITS)))
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
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
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14208
==
Reported By:Nils Gladitz
Assigned To:
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
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
> dashb
On 06/07/2013 09:13 AM, Stephen Kelly wrote:
>SOURCES $<$:other.cpp>
That has been requested as a feature occasionally. I'm not sure
it is possible to implement on all the generators though.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware
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() << "\"
Brad King wrote:
> On 06/07/2013 08:35 AM, Stephen Kelly wrote:
>> I looked into it a bit and found that the SOURCES target property already
>> exists. I was going to just add
>>
>>
>>
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 "
+
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 a
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14207
==
Reported By:Greg Eisenhauer
Assigned To:
On 06/07/2013 08:35 AM, Stephen Kelly wrote:
> I looked into it a bit and found that the SOURCES target property already
> exists. I was going to just add
>
>
>
Brad King wrote:
> On 06/07/2013 04:42 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> Oops, yes I meant TARGET_OBJECTS.
>>
>> And what is the trickyness with it?
>
> It is not currently tricky. I'm saying it may be tricky to
> convert the storage over to a sources target property.
> Perhaps i
On 06/07/2013 04:42 AM, Stephen Kelly wrote:
> Brad King wrote:
>> Oops, yes I meant TARGET_OBJECTS.
>
> And what is the trickyness with it?
It is not currently tricky. I'm saying it may be tricky to
convert the storage over to a sources target property.
Perhaps it is simpler than I think though
Brad King wrote:
> On 06/06/2013 11:15 AM, Stephen Kelly wrote:
>>> Also it may be tricky due to the way $ is
>>> currently handled up front.
>>
>> You mean TARGET_OBJECTS? It seems to only populate a ObjectLibraries
>> container which is later only used at generate-time. Or do you mean
>> someth
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
dis
21 matches
Mail list logo
