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:
Hi all,
I noticed that, as of CMake 2.8.10, the variable
CMAKE_languageName_COMPILER_WORKS is no longer cached. This breaks
some of my code.
I have wrapped find_package() into a my own project-specific
CMake-function myproject_find_package(). In one of my Find*.cmake
files I do a
Hi all,
I'm puzzled w.r.t. the behavior of enable_language(... OPTIONAL).
When trying to enable Fortran optionally on a system without a working
Fortran compiler (/usr/bin/f95 is a dead symbolic link) I get:
CMAKE_Fortran_COMPILER = /usr/bin/f95
CMAKE_Fortran_COMPILER_WORKS = TRUE
which is
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 815d42dafada77633b9f5bd9013ff38a65b9b4e7 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via a2a90b601a92f3f836eb2bb3511dccc1f761cef5 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The annotated tag, v2.8.11.1 has been created
at fcca05ebcdeb8ff0fd657b7d0da6a5ba822ef578 (tag)
tagging
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index c707023..6452cd3 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
set(CMake_VERSION_MAJOR 2)
set(CMake_VERSION_MINOR 8)
set(CMake_VERSION_PATCH 11)
-set(CMake_VERSION_TWEAK 20130607
26 matches
Mail list logo
