Re: [CMake] CMP0054 and CMake Modules

I can't find a bug report on this. Is there one? Surely Cmake distributed modules should not generate this type of warnings. Or am I misinterpreting the messages? I'm encountering numerous such problems/warnings in Cmake distributed modules: CMake Warning (dev) at

Re: [CMake] CMP0054 and CMake Modules

Sorry, this turned out kind of brief, it was posted in context in Nabble. I'm seeing this on Cygwin. /Thomas thoni56 21 september 2015 09:37 I can't find a bug report on this. Is there one? Surely Cmake distributed modules should not generate this type of

[CMake] How to create a custom solution with Visual Studio 2010 generator?

Hi, I'm trying to create a solution with custom set of projects (in VS sense) for Visual Studio 2010. I have a top level CMakeLists.txt with PROJECT() declared and then several CMakeLists.txt below in a tree also with PROJECT() in each of them. However for lower level PROJECT() directives I get

Re: [CMake] CMP0054 and CMake Modules

On 09/21/2015 09:37 AM, thoni56 wrote: Quoted variables like "" will no longer be dereferenced when the policy is You apparently have a variable whose name is the empty string. With the old (pre CMP0054) behavior this will break comparisons with empty strings take e.g. set(""

Re: [CMake] Port from Debian to Windows: Include files not found

Thanks for all of the input, everyone! Unfortunately the problem still persists. I don't have much to report this morning. I've removed the calls to build the assembly file and confirmed that it is an ASM vs C issue as opposed to an ordering issue. It continued to attempt to build the C file

Re: [CMake] How to create a custom solution with Visual Studio 2010 generator?

This may be a solution, I will check this asap. This should be clearer, I have something like this: Main Project - PROJECT() \Sub Project 1 - PROJECT() \target 1 - ADD_LIBRARY() \target 2 - ADD_LIBRARY()

Re: [CMake] Continued issues in trying to get CMake working on OpenVMS

I will try adding that option and see what it may reveal... the output contained in the CMakeOutput.log and CMakeError.log offered nothing other than politely telling me the test failed. -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman Sent:

Re: [CMake] Continued issues in trying to get CMake working on OpenVMS

On 9/21/2015 11:29 AM, Custin, Jay (CSC Sw Middleware) wrote: I will try adding that option and see what it may reveal... the output contained in the CMakeOutput.log and CMakeError.log offered nothing other than politely telling me the test failed. That is odd... It should have the

[CMake] Continued issues in trying to get CMake working on OpenVMS

So I ran into a few minor issues compiling/linking the CMake images (compiler threw a few "warnings" which didn't really prove significant so I simply "silenced" the warnings to enable the code to compile clean and link). I accomplished this with the following: bash$ export

Re: [CMake] How to create a custom solution with Visual Studio 2010 generator?

CMake's PROJECT directive maps to 'Solution' (should only be one project() per chain) ... use set( PROJECT projectname) and then reference ${PROJECT} later instead of ${PROJECT_NAME} for easy conversion. add_library, add_executable map to 'project' from

Re: [CMake] Continued issues in trying to get CMake working on OpenVMS

On 9/21/2015 10:17 AM, Custin, Jay (CSC Sw Middleware) wrote: This gets made even more frustrating in that it appears that the testing phase does a VERY good job cleaning up after itself... So, the output should all be in CMakeOutput.log and CMakeError.log found in the build tree in the

[CMake] add(library foo SHARED...) is not creating a PDB file

I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 This is the snipped of my CMakeLists.txt file add_library(commoncpp_objects OBJECT ) add_library(commoncpp_static STATIC $) add_dependencies(commoncpp_static commoncpp_objects) add_library(commoncpp SHARED $

Re: [CMake] CMP0054 and CMake Modules

Aahh, I was looking at the trace and it only included "include":s so I thought that offending IF was in cmake's own files since it pointed there. But, you are saying that probably the culprit is a variable set before the first include, right? (It was definitely not by intention a variable was as

Re: [CMake] CMP0054 and CMake Modules

On 09/21/2015 10:24 AM, thoni56 wrote: Aahh, I was looking at the trace and it only included "include":s so I thought that offending IF was in cmake's own files since it pointed there. But, you are saying that probably the culprit is a variable set before the first include, right? (It was

Re: [CMake] CMP0054 and CMake Modules

Also, this does not happen on MacOSX with Macports cmake. But does on Cygwin. thoni56 wrote > > Nils Gladitz-2 wrote >> On 09/21/2015 09:37 AM, thoni56 wrote: >>>Quoted variables like "" will no longer be dereferenced when the >>> policy is >> >> You apparently have a variable whose name is

[Cmake-commits] CMake branch, next, updated. v3.3.2-3183-g58c4057

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 58c40573e265ae38d64738cf4033373df0f2a6a5 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1245-gdce7d8b

_VERSION_MINOR 3) -set(CMake_VERSION_PATCH 20150921) +set(CMake_VERSION_PATCH 20150922) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

[Cmake-commits] CMake branch, next, updated. v3.3.2-3141-g95d21a8

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 95d21a818a0531e148c527c0c64d176c812e718e (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3150-gdec07ad

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 dec07adacff8a62c0c68b4ab3caf0f2be03aa45a (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1232-g4f640af

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, master has been updated via 4f640afc1aa571a4a1a9083b62e3d2787db84bf3 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1228-g82a0c7b

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, master has been updated via 82a0c7be3f6a00119f3ba00b0d1a4f73cbbb140c (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1236-gdd8285c

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, master has been updated via dd8285c6880e08e4c6cbb0e2ca1a1684df3e11d1 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1241-g1f43581

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, master has been updated via 1f4358134f2cf5b9fe72088d6534084a8fb71a52 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1239-g38830fc

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, master has been updated via 38830fc0cabb742cf95160429cc99cdb5326cce7 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3143-gb1c162f

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 b1c162ff8874a23434e314254f00b91e9efd699a (commit) via

Re: [cmake-developers] Add command line options for deprecation message control

On 09/19/2015 06:32 PM, Michael Scott wrote: > whether the -W options are intended to only be applicable > for the message command (and so the current behaviour is correct), > or whether they should affect all author and deprecated messages > output by other parts of CMake? The -Wdev/-Wno-dev

Re: [cmake-developers] CPack/NSIS is broken after extended length paths fix

On Monday, September 21, 2015 12:28:37 PM Dmitry Kochkin wrote: > Hi Clint, > > >>Actually it's even worse because in current master HEAD I can see that > >>INST_DIR is empty in generated project: !define INST_DIR "" > >>(not sure if that's caused by your change) > > > >Interesting... Do you

[Cmake-commits] CMake branch, next, updated. v3.3.2-3157-g7defd7c

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 7defd7c0006bbdf054c85ada3508b8bb7487da86 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3159-g98366c3

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 98366c3d0b5bd189e0aee10bf8846b38f07d4ccc (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1244-gcec45e2

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, master has been updated via cec45e27f6dc2657b00902bcaef5bd93ae16ead7 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3161-g451505b

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 451505b3bb8a400552c99d31e9f0c26f15fa3059 (commit) via

[cmake-developers] [CMake 0015753]: CMake cannot detect changes in nested header files when using '-iquote'

The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15753 == Reported By:danilcha Assigned To:

[Cmake-commits] CMake branch, next, updated. v3.3.2-3155-g47462f4

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 47462f48357918309a2019510586bae2410ddcb7 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3172-gda378b6

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 da378b6182c89d31d97524efd086fcb119ef0572 (commit) via

Re: [cmake-developers] generator expression for path slash conversion

Ah, thank you very much! I was confused as the distinction between WIN32 and UNIX worked nevertheless. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Montag, 21. September 2015 16:17 To: Kislinskiy, Stefan Cc: CHEVRIER, Marc; cmake-developers@cmake.org; James

[Cmake-commits] CMake branch, next, updated. v3.3.2-3170-gf7b8e9f

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 f7b8e9fc7446ba57138811776dac5a06acfd3f06 (commit) via

Re: [cmake-developers] Generator expressions for install destination

On 09/18/2015 03:49 PM, Robert Goulet wrote: > Here's a version that is more conservative. It doesn't change > the install(EXPORT) behavior. > install(TARGET) already supported genex Right. I'd forgotten about these changes: install: Allow generator expressions in TARGETS DESTINATION (#14317)

[Cmake-commits] CMake branch, next, updated. v3.3.2-3163-ge723550

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 e723550b1a75d8a9e7b4615bbf7037eb2ba1 (commit) via

[cmake-developers] [CMake 0015755]: add_dependencies() undoes include_directories()

The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15755 == Reported By:Dimitri Merejkowsky Assigned To:

[Cmake-commits] CMake branch, next, updated. v3.3.2-3165-g8831ba6

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 8831ba64a606c4eae7e16e41a83533711c075bf0 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3168-gf7b4f40

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 f7b4f40af838f66acbef763f215d697dd12cdff6 (commit) via

Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

On 09/18/2015 02:24 PM, Brad King wrote: > After working out the support for manifests across all generators > as discussed elsewhere in this thread, I've added your manifest > file to CMake's own build: > > Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) >

Re: [cmake-developers] generator expression for path slash conversion

I wrote the documentation and extended the GeneratorExpression tests for the SHELL_PATH genex. It works fine for WIN32 and UNIX. However, I'm having some trouble to test for MSYS. The check looks like: if(MSYS) check(test_shell_path "/c/shell/path") elseif(WIN32) check(test_shell_path

Re: [cmake-developers] generator expression for path slash conversion

On 09/21/2015 10:05 AM, Kislinskiy, Stefan wrote: > if(MSYS) > check(test_shell_path "/c/shell/path") > elseif(WIN32) > check(test_shell_path "c:shellpath") > elseif(UNIX) > check(test_shell_path "c:/shell/path") > endif() > > No matter what I'm doing, it always ends up in the WIN32

Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

On 09/18/2015 02:58 PM, James Johnston wrote: > While on the subject, there are some other additions to the manifest you > might want to consider. I think these are worth considering but we're too close to the 3.4 freeze to make these changes now. Please look at adding these during post-3.4

[cmake-developers] [CMake 0015754]: Visual Studio incremental build not working properly when target names start with a capital letter

The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15754 == Reported By:Johannes Asal Assigned To:

[Cmake-commits] CMake branch, next, updated. v3.3.2-3176-g6930abc

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 6930abc0d88ae587a717b9343780ac32499da4c1 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3174-g8db1b40

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 8db1b40ef504bc2ac102877bc767d608891d16f4 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3178-g6685dcd

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 6685dcd54221f56e1047142fd728000c9484101a (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3180-g6d9d704

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 6d9d7045893e99bc713958ec93f30fcf62555b6f (commit) via

[cmake-developers] [CMake 0015756]: FindLua.cmake doesn't work when both Lua5.2 and Lua5.3 are installed.

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15756 == Reported By:Alan Witkowski Assigned To:

Re: [cmake-developers] Add command line options for deprecation message control

The -Wdev/-Wno-dev options have always been for all messages output by any part of CMake. This needs to be preserved/corrected. Okay, I've fixed the change to cmake::PrintMessagePreamble, so that it'll stop warning or error dev or deprecated messages getting printed out when the relevant CMake

Re: [cmake-developers] CPack/NSIS is broken after extended length paths fix

Hi Clint, >>Actually it's even worse because in current master HEAD I can see that >>INST_DIR is empty in generated project: >>  !define INST_DIR "" >>(not sure if that's caused by your change) >Interesting... Do you know why this happens?  How is this problem related to >extended paths (with