Re: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison

2014-09-19 Thread Nils Gladitz
On 09/19/2014 07:30 AM, James Bigler wrote: Could someone please explain to me why we need to change all the if statements to look super ugly? It sounds like you might have missed the follow up within this thread. Expanding WIN32 to dereference the value is just a recipe for confusion.

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Nils Gladitz
On 09/19/2014 08:59 AM, Jiri Malak wrote: I did a several fixes to CMake related to Open Watcom which were accepteed to current development branch a few month ago. Up to now they were not included to official version 3.0 branch. What I must do to be include or I doing something wrong? The

Re: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison

2014-09-19 Thread Adam Strzelecki
Since the policy may or may not be active (depending on the user's project) they might be using FindCUDA.cmake with CMP0054 set to NEW or OLD. To get identical (and warning free) behavior irregardless of the current policy setting Adam added the proposed ugliness. Putting my 2ยข, we can

Re: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison

2014-09-19 Thread David Cole via cmake-developers
I like the cmake_policy(SET CMP0053 NEW) solution, too. We should make a concerted effort to encourage module maintainers to do this before the 3.1 release for as many modules as possible. D -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Nils Gladitz
On 09/19/2014 12:40 PM, Jiri Malak wrote: OK, but it was accepted before v3.0.0 was released. Do you know what rules are applied for selection what will be in new release and what cutoff date for it? On Feb. 19 2014 Brad announced the cutoff [1]. So everything that was in master before that

Re: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE

2014-09-19 Thread Bach, Pascal
If you don't mind, please precede this patch with a change that adds such subsection headers for the Clang and QCC cases. Bellow you find the updated patch, I rearranged the cross compiling section a bit and added subsections. Pascal From 01aa7fd739ff6bdaf05f882199e79549a04f7bda Mon Sep 17

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread David Cole via cmake-developers
The rule is (roughly): after the first release candidate for a given release, no more new features for that particular release. Only continuing work to complete new features in rc1 and fixing regressions reported from previous versions should go in subsequent release candidates. Possible

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Jiri Malak
On 09/19/2014 12:40 PM, Jiri Malak wrote: OK, but it was accepted before v3.0.0 was released. Do you know what rules are applied for selection what will be in new release and what cutoff date for it? On Feb. 19 2014 Brad announced the cutoff [1]. So everything that was in master before

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Nils Gladitz
On 09/19/2014 01:57 PM, Jiri Malak wrote: Thanks for info. It is clear, it was too late to be included to 3.0. Do you have any idea when version 3.1 first release candidate is planned? Mantis (the issue tracker) currently has 3.1 scheduled for 2014-11-01. For now I'd take it as a non binding

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Jiri Malak
On 09/19/2014 01:57 PM, Jiri Malak wrote: Thanks for info. It is clear, it was too late to be included to 3.0. Do you have any idea when version 3.1 first release candidate is planned? Mantis (the issue tracker) currently has 3.1 scheduled for 2014-11-01. For now I'd take it as a non

[cmake-developers] [CMake 0015165]: WiX : Remember the INSTALL_ROOT directory for upgrades

2014-09-19 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15165 == Reported By:Richard Ulrich Assigned To:

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Richard Shaw
On Fri, Sep 19, 2014 at 1:59 AM, Jiri Malak malak.j...@gmail.com wrote: Hi, I did a several fixes to CMake related to Open Watcom which were accepteed to current development branch a few month ago. Up to now they were not included to official version 3.0 branch. What I must do to be

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Richard Shaw
On Fri, Sep 19, 2014 at 8:34 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 09/19/2014 03:19 PM, Richard Shaw wrote: I'd like to hear others opinions, but what I've done is once one of my patches is accepted, as long as it applies cleanly to the current release (and since all I mess with

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Rolf Eike Beer
Richard Shaw wrote: On Fri, Sep 19, 2014 at 1:59 AM, Jiri Malak malak.j...@gmail.com wrote: I did a several fixes to CMake related to Open Watcom which were accepteed to current development branch a few month ago. Up to now they were not included to official version 3.0 branch. What I must

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Nils Gladitz
On 09/19/2014 03:19 PM, Richard Shaw wrote: I'd like to hear others opinions, but what I've done is once one of my patches is accepted, as long as it applies cleanly to the current release (and since all I mess with are modules that's usually the case) then I just email the Fedora package

Re: [cmake-developers] What is necessary for including fixes from current development branch to official release

2014-09-19 Thread Nils Gladitz
On 09/19/2014 03:40 PM, Richard Shaw wrote: I guess I could have copied the module into my project module folder and applied it locally, but that seems like a worse workaround than patching at the distro level. I think I would personally prefer that over changing the package for the whole

Re: [cmake-developers] vs-nsight-tegra-generator topic

2014-09-19 Thread Brad King
On 09/16/2014 06:11 PM, Mourad Boufarguine wrote: So, today I tried the next branch with the new NSight stuff. Great, thanks for testing it out. 1 (...)/arm-linux-androideabi/bin/ld.bfd.exe: cannot find -l-lGLESv1_CM This should fix it: VS: Fix Tegra-Android platform linking of libraries

Re: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE

2014-09-19 Thread Brad King
On 09/19/2014 06:59 AM, Bach, Pascal wrote: Bellow you find the updated patch, I rearranged the cross compiling section a bit and added subsections. Thanks. I split that into two commits with slight edits, and added my own commit to add subsections for Windows Phone and Store: Help: Add

[cmake-developers] Patch: Certificate files are not included in Windows Store projects

2014-09-19 Thread Gilles Khouzam
We do write the proper tag in the VCXProj file for the certificate file, but the file is not included in the project itself causing some failures. When I moved the certificates into their own category in the GeneratorTarget, the new category was never added to the VS10TargetGenerator when the

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-19 Thread Brad King
On 09/18/2014 08:10 PM, Aleix Pol wrote: I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to enable the generation of the file. I also renamed the file to ProjectTargets.json. http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch Thanks. I made some style updates and

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-19 Thread Brad King
On 09/19/2014 01:57 PM, Rolf Eike Beer wrote: I see duplicated slashes in the JSON file. It looks like those come from cmTarget::GetLocationForBuild. An extra + if(!location.empty()) +{ +location += /; +} appears to have been added by this commit: Remove the Location member from

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-19 Thread Alexander Neundorf
On Friday, September 19, 2014 13:44:45 Brad King wrote: ... * Don't IDEs want to know the list of source files so they can be used for editing? I haven't looked at what the Extra generators produce in a while but since they are meant for IDEs they would be a good reference for the

Re: [cmake-developers] [CMake] Integrating ExternalData with Artifactory

2014-09-19 Thread Taylor Braun-Jones
Shifting discussion to cmake-developers. On Fri, Sep 19, 2014 at 3:04 PM, Brad King brad.k...@kitware.com wrote: On 09/19/2014 12:23 PM, Taylor Braun-Jones wrote: integrate Artifactory with the ExternalData framework? the Artifactory REST API is a two step process I think it can be

Re: [CMake] Code Coverage Bullseye

2014-09-19 Thread Rajeev Kumar
Thou shall receive the patch :) On Thu, Sep 18, 2014 at 5:56 PM, David Cole dlrd...@aol.com wrote: My apologies. I take it back -- gcov apparently does work on the Mac nowadays. It is a ctest issue, then, and when using Xcode, ctest will need to look in some additional locations for the

[CMake] Problem compiling clang on cygwin, library prefix mismatch

2014-09-19 Thread Guilherme
Hello, When generating the cmake file all goes well but during compilation it fails. One of the messages is: Linking CXX shared library ../../bin/cygLLVMSupport.dll Where you can see that it has added the cyg prefix to the generated lib. But all the other targets search for libLLVMSupport.dll,

Re: [CMake] Problem compiling clang on cygwin, library prefix mismatch

2014-09-19 Thread Nils Gladitz
On 09/19/2014 10:55 AM, Guilherme wrote: Hello, When generating the cmake file all goes well but during compilation it fails. One of the messages is: Linking CXX shared library ../../bin/cygLLVMSupport.dll Where you can see that it has added the cyg prefix to the generated lib. But all the

Re: [CMake] Problem compiling clang on cygwin, library prefix mismatch

2014-09-19 Thread Guilherme
The output i see on the command line is: make[2]: *** No rule to make target 'lib/libLLVMSupport.dll.a', needed by 'bin/cygLLVMLineEditor.dll'. Stop. Well i'm trying to build all as shared. On Fri, Sep 19, 2014 at 11:07 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 09/19/2014 10:55 AM,

Re: [CMake] Problem compiling clang on cygwin, library prefix mismatch

2014-09-19 Thread Nils Gladitz
On 09/19/2014 11:17 AM, Guilherme wrote: The output i see on the command line is: make[2]: *** No rule to make target 'lib/libLLVMSupport.dll.a', needed by 'bin/cygLLVMLineEditor.dll'. Stop. Well i'm trying to build all as shared. So it is correctly looking for the import library

Re: [CMake] Problem compiling clang on cygwin, library prefix mismatch

2014-09-19 Thread Marco Atzeri
On 19/09/2014 11:17, Guilherme wrote: The output i see on the command line is: make[2]: *** No rule to make target 'lib/libLLVMSupport.dll.a', needed by 'bin/cygLLVMLineEditor.dll'. Stop. Well i'm trying to build all as shared. on cygwin, the build system usually produce something like: $

[CMake] Integrating ExternalData with Artifactory

2014-09-19 Thread Taylor Braun-Jones
Hi all, I'm curious if anyone has attempted to integrate Artifactory with the ExternalData framework? Unfortunately the Artifactory REST API is a two step process where you first search for a file based on MD5 or SHA1 hash[1] which returns JSON results the file's URI. You then issue a second

Re: [CMake] Integrating ExternalData with Artifactory

2014-09-19 Thread Brad King
On 09/19/2014 12:23 PM, Taylor Braun-Jones wrote: integrate Artifactory with the ExternalData framework? the Artifactory REST API is a two step process Currently ExternalData always uses the file(DOWNLOAD) command. Recently I was thinking about how to extend the ExternalData module to support

[Cmake-commits] CMake branch, next, updated. v3.0.2-5382-g1dd552c

2014-09-19 Thread Brad King
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 1dd552cb9e698232d4f1ff2648793497d000a8f3 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.0.2-5387-g997fd88

2014-09-19 Thread Brad King
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 997fd8865c8563f5d384b141e75f26bcea38e58b (commit) via

[Cmake-commits] CMake branch, next, updated. v3.0.2-5389-g04aed0b

2014-09-19 Thread Brad King
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 04aed0b7c46aa0c884e714c60ef25261d072d384 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.0.2-5391-gf7829f4

2014-09-19 Thread Nils Gladitz
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 f7829f46855d14b86fc74fb2988b4cb386ab2428 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.0.2-1876-g151bf1a

2014-09-19 Thread Kitware Robot
20140919) +set(CMake_VERSION_PATCH 20140920) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake