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

> -Original Message- > From: J Decker [mailto:d3c...@gmail.com] > Sent: Tuesday, September 22, 2015 8:12 AM > To: Golebiewski, Jakub > Cc: cmake@cmake.org > Subject: Re: [CMake] How to create a custom solution with Visual Studio > 2010 generator? > > On Mon, Sep 21, 2015 at 10:39 PM, Golebi

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

On Mon, Sep 21, 2015 at 10:39 PM, Golebiewski, Jakub wrote: > 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()

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()

[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 $ co

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 stderr/stdo

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: Monda

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

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 http://www.cmake.org/Wiki/CMake_Useful_Var

[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 CFLAGS="-Wc/warning

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 withou

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 defini

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 t

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 h

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("" foo

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 warning

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 /usr/share/cmake-3.3.1/Modul