date:20160822

[CMake] Xcode generator problems

2016-08-22 Thread Robert Bielik

Hi all,

I just opened https://gitlab.kitware.com/cmake/cmake/issues/16260, anyone have 
ideas how to work around it ? Or if it is fixed in latest & greatest CMake ?

Regards
/Robert
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] MACOSX_PACKAGE_LOCATION and iOS

2016-08-22 Thread Craig Scott

Just wondering if this is expected behaviour (it's not documented if it
is). When building for iOS with the Xcode generator, if a source file has
its MACOSX_PACKAGE_LOCATION property set, the generated Xcode project shows
that "../" is prepended to the path given. I'm wondering if the assumption
here is that for OSX, files will likely be getting put in "Resources/...",
but for iOS it is a flat structure with no Resources folder, so CMake
silently pulls the destination dir up one level. This seems like trying to
do too much on behalf of the developer, but let's first confirm whether
this is intended and debate the merits later. ;)

-- 
Craig Scott
Melbourne, Australia
http://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Bash on ubuntu on windows as target

2016-08-22 Thread Gilles Khouzam via CMake

I’ve looked more in depth at the issue, and while this doesn’t work yet, we’re 
looking to enable this in a future Windows Insider Flight for better 
windows/linux interop.

From: Gilles Khouzam
Sent: Monday, August 15, 2016 13:24
To: 'Tiago Macarios' ; csiga.b...@aol.com
Cc: CMake ML 
Subject: RE: [CMake] Bash on ubuntu on windows as target

That’s an interesting idea,

I’m not sure why cmd is failing to invoke bash properly, but I will try and 
figure it out.

Also, for addressing invoking bash.exe without copying it to SysWow64, you can 
reference it by C:\Windows\Sysnative\bash.exe from a 32-bit process. It still 
doesn’t make the target succeed, but at least it removes the need to copy the 
file around.

Thanks
~Gilles

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Tiago Macarios
Sent: Thursday, August 11, 2016 10:12
To: csiga.b...@aol.com
Cc: CMake ML mailto:cmake@cmake.org>>
Subject: Re: [CMake] Bash on ubuntu on windows as target

Well what I was trying to do was to actually have a target inside the windows 
build that would trigger the linux build so to build both at the same time. 
imagine you have a VS project one of the "projects" would be the linux build. 
So as long as the build folder is different I could have both building in sync 
everytime. Get the idea?

If I just do a full build inside bash everything works great =)

On Wed, Aug 10, 2016 at 11:23 PM, <"Máté Ferenc Nagy-Egri via CMake 
mailto:%22Máté%20Ferenc%20Nagy-Egri%20via%20CMake%20%3ccmake@cmake...@public.kitware.com>>
 wrote:
+1 for the initiative. Wouldn’t it make more sense however to make it a 
CMAKE_SYSTEM_NAME? If I remember correctly that’s how MinGW works, and this 
should be something very similar.

Feladó: Tiago Macarios
Elküldve: 2016. augusztus 11., csütörtök 1:51
Címzett: CMake ML
Tárgy: [CMake] Bash on ubuntu on windows as target

Hi All,

Windows 10 anniversary edition comes with support to execute Linux binaries. I 
have been trying to use it with one of our projects, but I have been getting a 
weird error. Maybe someone can help me?

The target is pretty simple:

set(BASH "C:\\Windows\\System32\\bash.exe")
set(ARGS "--help")
add_custom_target(linux ${BASH} ${ARGS})

If I then build that project in visual studio (with some extra verbosity) I get:

Target "CustomBuild" in file "C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets" from project 
"C:\_Working\delegate\build\linux.vcxproj" (target 
"_BuildGenerateSourcesAction" depends on it):
Using "CustomBuild" task from assembly "C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build.CppTasks.Common.dll".
Task "CustomBuild"
  Write Tracking Logs:
   x64\Debug\linux\linux.tlog\custombuild.write.1.tlog
  Read Tracking Logs:
   x64\Debug\linux\linux.tlog\custombuild.read.1.tlog
  No output for 
C:\_WORKING\DELEGATE\BUILD\CMAKEFILES\3FA5525E877A7559336C7D412E1B43B0\LINUX.RULE|C:\_WORKING\DELEGATE\CMAKELISTS.TXT
 was found in the tracking log; source compilation required.
  C:\_Working\delegate\CMakeLists.txt will be compiled as it was not found in 
the tracking log.

C:\_Working\delegate\build\CMakeFiles\3fa5525e877a7559336c7d412e1b43b0\linux.rule
 will be compiled as it was not found in the tracking log.
  setlocal
  "C:\Program Files (x86)\CMake\bin\cmake.exe" -HC:/_Working/delegate 
-BC:/_Working/delegate/build --check-stamp-file 
C:\_Working\delegate\build\CMakeFiles\generate.stamp
  if %errorlevel% neq 0 goto :cmEnd
  :cmEnd
  endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
  :cmErrorLevel
  exit /b %1
  :cmDone
  if %errorlevel% neq 0 goto :VCEnd
  setlocal
  C:\Windows\System32\bash.exe --help
  if %errorlevel% neq 0 goto :cmEnd
  :cmEnd
  endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
  :cmErrorLevel
  exit /b %1
  :cmDone
  if %errorlevel% neq 0 goto :VCEnd
  Building Custom Rule C:/_Working/delegate/CMakeLists.txt
  CMake does not need to re-run because 
C:\_Working\delegate\build\CMakeFiles\generate.stamp is up-to-date.
C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error 
MSB6006: "cmd.exe" exited with code -1073740791.
Done executing task "CustomBuild" -- FAILED.
Done building target "CustomBuild" in project "linux.vcxproj" -- FAILED.

The command line seems correct. If I just copy it to the windows prompt it 
works fine:

C:\Users\tmc>  C:\Windows\System32\bash.exe --help
GNU bash, version 4.3.11(1)-release-(x86_64-pc-linux-gnu)
Usage:  /bin/bash [GNU long option] [option] ...
/bin/bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--rcfile
--restricted
--verbose
--version
Sh

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread Nils Gladitz


On 22.08.2016 19:34, Albrecht Schlosser wrote:


So, the conclusion is: since CMake can't figure it out we have to 
_assume_ that the header files can be #included in MSVC projects 
(MinGW works well), hence we should set the corresponding CMake 
variable to true, maybe something like:


if (MSVC)
  set (HAVE_GL_GL_H 1)
endif (MSVC)

Is this what you suggest?


I suppose I'd go with if(WIN32).

Nils


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread Albrecht Schlosser


On 22.08.2016 14:12 Nils Gladitz wrote:

On 08/22/2016 01:30 PM, Albrecht Schlosser wrote:


On 22.08.2016 12:54 Nils Gladitz wrote:

On 08/22/2016 12:18 PM, Albrecht Schlosser wrote:


On 22.08.2016 10:33 Nils Gladitz wrote:


The visual studio command line environments should have no effect when
using the visual studio generators.


Are you sure? Or what does "should" mean here? ;-)


Yes. The Visual Studio generators are meant to work outside of the
visual studio command line environments while the command line
generators (makefiles, ninja) are meant to work from within the visual
studio command line environment.

What that means is that the Visual Studio generators must work
without it.


Okay, I posted a simple example CMake file to show what happens in my
case. See new thread:

"Visual Studio generator does not find some header files"

Basically some special (SDK?) header files are not found when
executing CMake w/o the Visual Studio environment.



E.g. CMake find_path() uses the INCLUDE environment variable (which is
provided by the visual studio command line environment) if set.

So yes this can influence CMake itself but not Visual Studio.
Since the paths in the INCLUDE environment variable are not used by
Visual Studio this can result in obvious conflicts.


Okay, I see.


Since CMake does not (I don't know if it (easily) could) know the
implicit include directories Visual Studio uses it can not use them in
find_*() calls either.


Understood. Thanks for the information.


In case of the OpenGL library (which on windows is part of the
windows/platform SDK) cmake e.g. assumes (within the FindOpenGL.cmake
module) that the header is in an implicit include directory and does not
try to locate it.


Well, that's a pity. This makes it necessary to use platform specific 
code in CMake files unless you can completely rely on modules that do 
already include such platform specify code.



Assuming this matches your use case I would suggest you do the same.


Indeed our case in FLTK (www.fltk.org), a cross platform GUI library 
(for those that don't know it) is related to OpenGL (GL/gl.h and 
GL/glu.h), but also locale.h. We need to know if we can #include these 
(and other) header files in the library code.


I took a look into our old bundled IDE files and found that we _assumed_ 
that these headers existed even in our oldest supported Visual C++ IDE 
(the provided config.h file was edited accordingly).


So, the conclusion is: since CMake can't figure it out we have to 
_assume_ that the header files can be #included in MSVC projects (MinGW 
works well), hence we should set the corresponding CMake variable to 
true, maybe something like:


if (MSVC)
  set (HAVE_GL_GL_H 1)
endif (MSVC)

Is this what you suggest?

This would work, but it's very unfortunate to have to do this. It would 
be much better if find_file() or find_path() would be able to work 
really cross platform w/o special assumptions. But I see your point.



I'll take another look in our CMake files to see if find_package(OpenGL) 
would get us to

a better solution.

Thanks for your support.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread Nils Gladitz


On 08/22/2016 01:30 PM, Albrecht Schlosser wrote:


On 22.08.2016 12:54 Nils Gladitz wrote:

On 08/22/2016 12:18 PM, Albrecht Schlosser wrote:


On 22.08.2016 10:33 Nils Gladitz wrote:


The visual studio command line environments should have no effect when
using the visual studio generators.


Are you sure? Or what does "should" mean here? ;-)


Yes. The Visual Studio generators are meant to work outside of the
visual studio command line environments while the command line
generators (makefiles, ninja) are meant to work from within the visual
studio command line environment.

What that means is that the Visual Studio generators must work 
without it.


Okay, I posted a simple example CMake file to show what happens in my 
case. See new thread:


"Visual Studio generator does not find some header files"

Basically some special (SDK?) header files are not found when 
executing CMake w/o the Visual Studio environment.




E.g. CMake find_path() uses the INCLUDE environment variable (which is 
provided by the visual studio command line environment) if set.


So yes this can influence CMake itself but not Visual Studio.
Since the paths in the INCLUDE environment variable are not used by 
Visual Studio this can result in obvious conflicts.


Since CMake does not (I don't know if it (easily) could) know the 
implicit include directories Visual Studio uses it can not use them in 
find_*() calls either.


In case of the OpenGL library (which on windows is part of the 
windows/platform SDK) cmake e.g. assumes (within the FindOpenGL.cmake 
module) that the header is in an implicit include directory and does not 
try to locate it.


Assuming this matches your use case I would suggest you do the same.

Nils
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Visual Studio generator does not find some header files

2016-08-22 Thread Albrecht Schlosser

I found an inconsistency when executing CMake directly from a desktop 
link vs. running it for instance from a "Developer Command Prompt for 
VS2015" _or_ executing CMake's (re)configure stage from within the 
Visual Studio environment after modifying one of the CMake files.


This seems to indicate that "something" is not set up correctly if I 
execute CMake directly (clicking the desktop link or running it from the 
Windows Explorer).


On 22.08.2016 12:54 Nils Gladitz wrote in another thread:

> The Visual Studio generators are meant to work outside of the
> visual studio command line environments while the command line
> generators (makefiles, ninja) are meant to work from within the visual
> studio command line environment.
>
> What that means is that the Visual Studio generators must work
> without it.

The following example CMakeLists.txt file seems to indicate that this is 
not true, at least for CMake 3.2.1. I'm currently not keen on installing 
another (newer) CMake version, but if this is fixed in a newer version I 
can do this.


System: Windows 10
Visual Studio 2015 Community 2015, Update 3
CMake 3.2.1

Here is my minimal CMakeLists.txt that is needed to run the configure 
step and show the results. Note that "other" header files are found w/o 
issues.


I can provide more (with a configure_file) if requested.

#-
# CMakeLists.txt
#-
cmake_minimum_required(VERSION 2.8)

project (find_headers)

find_file (HAVE_GL_GL_H GL/gl.h)
find_file (HAVE_GL_GLU_H GL/glu.h)
find_file (HAVE_LOCALE_H locale.h)

if (MSVC)
  message(STATUS "Note: The following three headers should all be found!")
  message(STATUS "HAVE_GL_GL_H = '${HAVE_GL_GL_H}'")
  message(STATUS "HAVE_GL_GLU_H = '${HAVE_GL_GLU_H}'")
  message(STATUS "HAVE_LOCALE_H = '${HAVE_LOCALE_H}'")
  message(STATUS "If one of these headers was not found, run cmake-gui 
...")
  message(STATUS "... again from a Visual Studio developer command 
prompt!")

endif (MSVC)
#-
# End of CMakeLists.txt
#-

# Run cmake-gui directly by clicking the installed desktop link
# to the cmake-gui executable
# Click 'configure'

The C compiler identification is MSVC 19.0.24213.1
The CXX compiler identification is MSVC 19.0.24213.1
Check for working C compiler using: Visual Studio 14 2015 Win64
Check for working C compiler using: Visual Studio 14 2015 Win64 -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler using: Visual Studio 14 2015 Win64
Check for working CXX compiler using: Visual Studio 14 2015 Win64 -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Note: The following three headers should all be found!
HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND'
HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND'
HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND'
If one of these headers was not found, run cmake-gui ...
... again from a Visual Studio developer command prompt!
Configuring done

# Repeating configure ...

Note: The following three headers should all be found!
HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND'
HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND'
HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND'
If one of these headers was not found, run cmake-gui ...
... again from a Visual Studio developer command prompt!
Configuring done

# Now executing "Developer Command Prompt for VS2015"

C:\Program Files (x86)\Microsoft Visual Studio 
14.0>c:\CMake\bin\cmake.exe --version

cmake version 3.2.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).

C:\Program Files (x86)\Microsoft Visual Studio 
14.0>c:\CMake\bin\cmake-gui.exe


# Clicking 'configure' in the same build directory configured before:

Note: The following three headers should all be found!
HAVE_GL_GL_H = 'C:/Program Files (x86)/Windows Kits/8.1/Include/um/GL/gl.h'
HAVE_GL_GLU_H = 'C:/Program Files (x86)/Windows 
Kits/8.1/Include/um/GL/glu.h'
HAVE_LOCALE_H = 'C:/Program Files (x86)/Windows 
Kits/10/Include/10.0.10240.0/ucrt/locale.h'

If one of these headers was not found, run cmake-gui ...
... again from a Visual Studio developer command prompt!
Configuring done

# End of log

As you can see, CMake finds the above mentioned headers when
executed from a "Developer Command Prompt for VS2015", but not
when executed directly by clicking the CMake desktop link or
clicking cmake-gui in the windows explorer.

Further tests show that CMake also finds the headers when it needs to 
reconfigure something within the VS IDE because a CMake file was changed.


Wild guess: given the paths of the header files in question I assume 
that it has something to do with the SDK files ('Windows 
Kits/8.1/Include/um/GL/...' and 'Windows 
Kits/10/Include/10.0.10240.0/ucrt/...'

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread Albrecht Schlosser


On 22.08.2016 12:54 Nils Gladitz wrote:

On 08/22/2016 12:18 PM, Albrecht Schlosser wrote:


On 22.08.2016 10:33 Nils Gladitz wrote:


The visual studio command line environments should have no effect when
using the visual studio generators.


Are you sure? Or what does "should" mean here? ;-)


Yes. The Visual Studio generators are meant to work outside of the
visual studio command line environments while the command line
generators (makefiles, ninja) are meant to work from within the visual
studio command line environment.

What that means is that the Visual Studio generators must work without it.


Okay, I posted a simple example CMake file to show what happens in my 
case. See new thread:


"Visual Studio generator does not find some header files"

Basically some special (SDK?) header files are not found when executing 
CMake w/o the Visual Studio environment.


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread Nils Gladitz


On 08/22/2016 12:18 PM, Albrecht Schlosser wrote:


On 22.08.2016 10:33 Nils Gladitz wrote:


The visual studio command line environments should have no effect when
using the visual studio generators.


Are you sure? Or what does "should" mean here? ;-)


Yes. The Visual Studio generators are meant to work outside of the 
visual studio command line environments while the command line 
generators (makefiles, ninja) are meant to work from within the visual 
studio command line environment.


What that means is that the Visual Studio generators must work without it.

You can of course create manual dependencies from your project e.g. when 
you manually run "cl" from a custom command but such use should 
obviously be avoided since it is non-obvious and there is nothing that 
prevents you from running e.g. the x86 environment while your visual 
studio solution (which will ignore that environment) is targeting amd64.


Nils
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread Albrecht Schlosser


On 22.08.2016 10:33 Nils Gladitz wrote:


The visual studio command line environments should have no effect when
using the visual studio generators.


Are you sure? Or what does "should" mean here? ;-)

I know of a case where running CMake (3.2.1) from the installed desktop
link does not find some headers that are found if I run CMake from
within a "Developer Command Prompt for VS2015".

Note: I did not use vcvarsall.bat explicitly.

Shall I post an example CMake file?

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread tonka tonka

Does cmake call vcvarall.bat itself?

Always call vcvarall.bat before cmake itself is not really a nice solution.

Setting/override CMAKE_CXX_COMPILER to the x64 toolchain could work, but it
depends on the question “does cmake call vcvarall.bat internally“

Am 22.08.2016 10:36 schrieb "J Decker" :

>
>
> On Mon, Aug 22, 2016 at 1:33 AM, Nils Gladitz 
> wrote:
>
>> On 08/22/2016 10:28 AM, J Decker wrote:
>>
>> Maybe you need a diferent parameter to vcvarsall before running cmake
>>
>> https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx
>>
>> >
>> How to: Enable a 64-Bit Visual C++ Toolset on the Command Line
>>
>>
>> To run vcvarsall.bat to use a 64-bit toolset
>>
>>1.
>>
>>At the command prompt, change to the Visual C++ installation
>>directory. (The location depends on the system and the Visual Studio
>>installation, but a typical location is C:\Program Files (x86)\Microsoft
>>Visual Studio *version*\VC\.) For example, enter:
>>
>> To configure this Command Prompt window for 64-bit command-line builds
> that target x86 platforms, at the command prompt, enter:
> *vcvarsall amd64_x86*
>
> *shjrug* the article spells it out.
>
>>
>> The visual studio command line environments should have no effect when
>> using the visual studio generators.
>> They should only be relevant when you use one of the command line
>> generators (e.g. makefiles or ninja).
>>
>> Nils
>>
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread J Decker

On Mon, Aug 22, 2016 at 1:33 AM, Nils Gladitz  wrote:

> On 08/22/2016 10:28 AM, J Decker wrote:
>
> Maybe you need a diferent parameter to vcvarsall before running cmake
>
> https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx
>
> >
> How to: Enable a 64-Bit Visual C++ Toolset on the Command Line
>
>
> To run vcvarsall.bat to use a 64-bit toolset
>
>1.
>
>At the command prompt, change to the Visual C++ installation
>directory. (The location depends on the system and the Visual Studio
>installation, but a typical location is C:\Program Files (x86)\Microsoft
>Visual Studio *version*\VC\.) For example, enter:
>
> To configure this Command Prompt window for 64-bit command-line builds
that target x86 platforms, at the command prompt, enter:
*vcvarsall amd64_x86*

*shjrug* the article spells it out.

>
> The visual studio command line environments should have no effect when
> using the visual studio generators.
> They should only be relevant when you use one of the command line
> generators (e.g. makefiles or ninja).
>
> Nils
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread Nils Gladitz


On 08/22/2016 10:28 AM, J Decker wrote:


Maybe you need a diferent parameter to vcvarsall before running cmake

https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx



The visual studio command line environments should have no effect when 
using the visual studio generators.
They should only be relevant when you use one of the command line 
generators (e.g. makefiles or ninja).


Nils
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread J Decker

Maybe you need a diferent parameter to vcvarsall before running cmake

https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx

On Mon, Aug 22, 2016 at 1:01 AM, Nils Gladitz  wrote:

> On 08/22/2016 09:27 AM, tonka tonka wrote:
>
> Hey,
>>
>> I have recently switched to cmake (instead of plain visual studio).
>> Now i discovered a problem.cmake choose the wrong cl.exe for my x64
>> project.
>>
>>
> I don't think CMake chooses the compiler when using the visual studio
> generators.
> Visual Studio chooses and CMake just records that choice in
> CMAKE__COMPILER.
>
> Nils
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] target_link_libraries and flags issue with Visual Studio

2016-08-22 Thread Louis-Paul CORDIER


Dear Guillaume,

Thank you for the suggestion. Unfortunately, it seems this option does 
not fill the linker property of the linking project.


Otherwise, it seems that STATIC_LIBRARY_FLAGS is adding the link 
properties to the 'librarian':


set_target_properties(lib_project PROPERTIES STATIC_LIBRARY_FLAGS 
"-level='requireAdministrator' -uiAccess='false'")


Any other suggestions? Thanks!

LP

Le 08/08/2016 à 02:45, Guillaume Dumont a écrit :

Hi,

You can use the LINK_FLAGS or LINK_FLAGS_ for this:

https://cmake.org/cmake/help/v3.6/prop_tgt/LINK_FLAGS.html

Have you tried that?

Guillaume

On Wed, Aug 3, 2016 at 7:02 AM, Louis-Paul CORDIER 
mailto:lp.cord...@dynamixyz.com>> wrote:


ase not t





--
Guillaume Dumont
=
dumont.guilla...@gmail.com 


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread Nils Gladitz


On 08/22/2016 09:27 AM, tonka tonka wrote:


Hey,

I have recently switched to cmake (instead of plain visual studio).
Now i discovered a problem.cmake choose the wrong cl.exe for my x64 
project.




I don't think CMake chooses the compiler when using the visual studio 
generators.
Visual Studio chooses and CMake just records that choice in 
CMAKE__COMPILER.


Nils
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread tonka tonka

Yes, i definitely choose the Win64 version.

Am 22.08.2016 09:50 schrieb "Kristian" :

> Did you already tried to use the "Visual Studio 10 2010 Win64" generator?
>
> * https://cmake.org/cmake/help/v3.6/generator/Visual%
> 20Studio%2010%202010.html
> * https://cmake.org/cmake/help/v3.6/manual/cmake-generators.7.html
>
> 2016-08-22 9:27 GMT+02:00 tonka tonka :
>
>> Hey,
>>
>> I have recently switched to cmake (instead of plain visual studio).
>> Now i discovered a problem.cmake choose the wrong cl.exe for my x64
>> project.
>> Cmake choose bin/x86_amd64/cl.exe which is the “x64 Cross Tools“. This
>> create x64 binaries, but with my big project I reach a out of memory linker
>> error, because the cl.exe is wrong (this cl.exe is an 32bit compiler which
>> can create x64 binaries).
>> Cmake should choose bin/amd64/cl.exe to use a “real“ x64 compiler.
>>
>> Does anybody know how I can tell cmake to do that?
>>
>> Compiler: visual studio 2010 sp1
>> OS: win 7 x64
>> Cmake: 3.4.3
>>
>> Greetings
>> Tonka
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Wrong version of cl.exe for x64

2016-08-22 Thread Kristian

Did you already tried to use the "Visual Studio 10 2010 Win64" generator?

*
https://cmake.org/cmake/help/v3.6/generator/Visual%20Studio%2010%202010.html
* https://cmake.org/cmake/help/v3.6/manual/cmake-generators.7.html

2016-08-22 9:27 GMT+02:00 tonka tonka :

> Hey,
>
> I have recently switched to cmake (instead of plain visual studio).
> Now i discovered a problem.cmake choose the wrong cl.exe for my x64
> project.
> Cmake choose bin/x86_amd64/cl.exe which is the “x64 Cross Tools“. This
> create x64 binaries, but with my big project I reach a out of memory linker
> error, because the cl.exe is wrong (this cl.exe is an 32bit compiler which
> can create x64 binaries).
> Cmake should choose bin/amd64/cl.exe to use a “real“ x64 compiler.
>
> Does anybody know how I can tell cmake to do that?
>
> Compiler: visual studio 2010 sp1
> OS: win 7 x64
> Cmake: 3.4.3
>
> Greetings
> Tonka
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Wrong version of cl.exe for x64

2016-08-22 Thread tonka tonka

Hey,

I have recently switched to cmake (instead of plain visual studio).
Now i discovered a problem.cmake choose the wrong cl.exe for my x64 project.
Cmake choose bin/x86_amd64/cl.exe which is the “x64 Cross Tools“. This
create x64 binaries, but with my big project I reach a out of memory linker
error, because the cl.exe is wrong (this cl.exe is an 32bit compiler which
can create x64 binaries).
Cmake should choose bin/amd64/cl.exe to use a “real“ x64 compiler.

Does anybody know how I can tell cmake to do that?

Compiler: visual studio 2010 sp1
OS: win 7 x64
Cmake: 3.4.3

Greetings
Tonka
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Xcode generator problems

[CMake] MACOSX_PACKAGE_LOCATION and iOS

Re: [CMake] Bash on ubuntu on windows as target

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

[CMake] Visual Studio generator does not find some header files

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] target_link_libraries and flags issue with Visual Studio

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

Re: [CMake] Wrong version of cl.exe for x64

[CMake] Wrong version of cl.exe for x64

19 matches

Site Navigation

Mail list logo

Footer information