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/Wik
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
he
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:
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)
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
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.
Ar
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 indicat
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? ;-)
Y
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 mean
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
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 Lin
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
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 visua
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_LIB
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
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
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
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
e
19 matches
Mail list logo
