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
Brad King wrote:
On 06/06/2013 11:15 AM, Stephen Kelly wrote:
Also it may be tricky due to the way $TARGET_SOURCES:... 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
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/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
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
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 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/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/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 09:13 AM, Stephen Kelly wrote:
SOURCES $$CONFIG:Debug: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
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
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: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
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)));
}
where
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
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
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?
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14209
==
Reported By:mwoehlke
Assigned To:
20 matches
Mail list logo