Stephen Kelly wrote:
Hi,
As part of implementing the INTERFACE_SOURCES feature, a SOURCES property
is required.
Unfortunately it already exists and does not contain all sources. It omits
TARGET_OBJECTS items. Backward compatibility must be preserved. I would
want to turn
On 02/21/2014 04:59 AM, Stephen Kelly wrote:
My preference is adding only string(GENEX_STRIP) to strip out genexes.
Yes.
The preference is to stick with SOURCES, right?
Yes, with associated policy for code that reads SOURCES to only get
what they do now in the OLD behavior.
Thanks,
-Brad
--
On Fri, Feb 21, 2014 at 08:38:35 +0100, Rolf Eike Beer wrote:
Are there any other corner cases I should consider banning as well? What
about behavior that should be allowed that currently isn't?
If this patch is the right place to address this is not clear to me, but I
mention them
On Fri, Feb 21, 2014 at 12:05 PM, Ben Boeckel ben.boec...@kitware.comwrote:
On Fri, Feb 21, 2014 at 08:38:35 +0100, Rolf Eike Beer wrote:
Are there any other corner cases I should consider banning as well?
What
about behavior that should be allowed that currently isn't?
If this patch
On 02/21/2014 02:18 PM, Jean-Christophe Fillion-Robin wrote:
If possible, not having implicit expansion for quoted argument
would be great at make things more intuitive and practical.
This has been discussed before. It will take some refactoring
of the CMake language command processing
Am Freitag, 21. Februar 2014, 14:51:19 schrieben Sie:
On Fri, Feb 21, 2014 at 14:18:02 -0500, Jean-Christophe Fillion-Robin wrote:
On Fri, Feb 21, 2014 at 12:05 PM, Ben Boeckel
ben.boec...@kitware.comwrote:
I agree in general, however, my CMake style is to quote all variable
expansions
On 02/21/2014 04:17 PM, Matthew Woehlke wrote:
Even without a branch, I'll risk stating that requiring 'if(FOO)' to
become 'if(${FOO})' is not likely to go over well :-)
IMO we should not be considering any change to implicit dereference
in unquoted arguments. At most we should make if(FOO)
On Fri, Feb 21, 2014 at 16:17:37 -0500, Matthew Woehlke wrote:
Even without a branch, I'll risk stating that requiring 'if(FOO)' to
become 'if(${FOO})' is not likely to go over well :-). (If nothing
else, I'll go ahead and object to such a change.) Probably implicit
expansion should be allowed
On 2014-02-21 16:34, Ben Boeckel wrote:
Other than varname, I don't really see a huge burden to not allowing
implicit dereferencing and it is more consistent at that point. In fact,
I'd be willing to say in varname that we *only* support implicit
dereference, but it may be too hard to detect:
On Fri, Feb 21, 2014 at 16:37:51 -0500, Brad King wrote:
IMO we should not be considering any change to implicit dereference
in unquoted arguments. At most we should make if(FOO) not do it.
Any reason why? In my search of VTK and ParaView, there are lots of
places which use statements like:
On Fri, Feb 21, 2014 at 17:11:27 -0500, Brad King wrote:
By limiting the change to quoted and bracket arguments we preserve
existing behavior in common existing code but allow authors to protect
themselves by quoting.
That also means I can't protect my code from things like:
set(evil
On 2/21/2014 5:37 PM, Ben Boeckel wrote:
That also means I can't protect my code from things like:
set(evil STREQUAL bogus OR TRUE OR )
if (PREFIX_${evil}_SUFFIX)
message(Evil prevails)
endif ()
by quoting the 'evil' expansion
We already agreed not to change the
On Fri, Feb 21, 2014 at 17:15:42 -0500, Ben Boeckel wrote:
On Wed, Feb 19, 2014 at 17:40:45 +0100, Stephen Kelly wrote:
By the way, I have only started working on policy CMP0051, not CMP0052, so
if you want to take the CMP0052 spot, that would take pressure off me to
implement it. Do you
Hi there,
I'm following up on this recent thread:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9324/focus=9330
Unfortunately, most of what was discussed there appears to involve advanced
CMake knowledge that I don't have. Would it be possible for someone to
look at the
On Fri, Feb 21, 2014 at 18:53:48 -0800, Dave Abrahams wrote:
I'm following up on this recent thread:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9324/focus=9330
Unfortunately, most of what was discussed there appears to involve advanced
CMake knowledge that I don't have.
Thanks, but as far as I can tell, only static libraries are involved here
On Fri, Feb 21, 2014 at 7:43 PM, Ben Boeckel ben.boec...@kitware.comwrote:
On Fri, Feb 21, 2014 at 18:53:48 -0800, Dave Abrahams wrote:
I'm following up on this recent thread:
The order of arguments is wrong.
Move the 'EXPORT foo-targets' to just after 'TARGETS foo'.
That fixed the issue. Shouldn't the WIKI be fixed so the example is correct?
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
David,
Indeed it should. Thanks for catching that! I've updated the wiki page
with the correct order of arguments.
- Chuck
On Fri, Feb 21, 2014 at 11:25 AM, david.hag...@gmail.com wrote:
The order of arguments is wrong.
Move the 'EXPORT foo-targets' to just after 'TARGETS foo'.
Great work folks improving the Java support. I still have a couple of issues
if anyone can help.
One is the issue with, http://public.kitware.com/Bug/view.php?id=14655, the
CMAKE_JAVA_TARGET_OUTPUT_DIR doesn't override OUTPUT_DIR. I disagree with the
issue being minor, because if you have a
On 2014-02-21 13:48, Allen Byrne wrote:
One is the issue with, http://public.kitware.com/Bug/view.php?id=14655, the
CMAKE_JAVA_TARGET_OUTPUT_DIR doesn't override OUTPUT_DIR.
Pedantic: if OUTPUT_DIR is given, it should override
CMAKE_JAVA_TARGET_OUTPUT_DIR. I think maybe you didn't mean to
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 6f5707c3e3f4e666f8d04fba1023597df825063a (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 ab944c0a09a165758f224c58fc1f2e6c4724c139 (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 854baa7a5fa143e9a8ae80bc1dcf901ad006decd (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 2b64ebbf44b56fe21e59ac6fd5904c6528cb8258 (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 21ae940bd13a79fb52730962e61265c5d54b23b4 (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 2ad6f07fc31047755a6450dfff715957e8d9091d (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 8b0b0ee4c227e4a8dad4a12dd7a79abc5c275f54 (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 2f164149ce6dfe7c9a5689ef523e9b3c16f69a2f (commit)
via
20140221)
+set(CMake_VERSION_PATCH 20140222)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
29 matches
Mail list logo
