I've the following configuration
Visual Studio 15.9.4
CMake 3.11
When I create a new cmake project from Visual Studio project templates, it starts configuring project as expected and cmake generation completes with no error. The output window of Visual Studio looks like this
1> -- Generating done
1> -- Build files have been written to: C:/Users/Dell/CMakeBuilds/0538efd0-8db3-fb3e-ba15-48b48c82580d/build/x64-Debug (default)
1> Starting CMake target info extraction ...
1> CMake server connection made.
1> Extracted includes paths.
1> Extracted CMake variables. 1> Extracted source files and headers.
1> Extracted global settings.
1> Extracted code model.
1> Extracted CTest info.
1> Collating data ...
1> Target info extraction done.
But the problem occurs when I try to build, no targets appear, cmake target view of solution explorer says it is still parsing CMakeLists.txt. When I tried to compile with command line it finishes with no error and I am able to run the program.
It is a bit hard to see what is going on since you don't show any source code, but I use cmake on the command line to generate solutions files and load them in Visual Studio 2017.
You just need to that once, when you update the CMakeLists.txt files you can save them and compiler them via CTRL + F7 and then reload the solution and project that has updated. This works for small changes.
I also found using cmake directly was very slow since I have a large project. It seems to work well in clion that I use on Linux.
Related
Introduction to the problem
I'm trying to create a MacOS app that prints a "Hello World" in C++ using Visual Studio 2022 (latest release 17.2.0) on Windows and the CMake template so I can connect remotely (using SSH) to the MacOS, I've been following this official Microsoft tutorial
Problem ocurred
The problem is that when I get to the installation step of CMake in MacOS I can't get it to recognize the version of MacOS installed since when I open the project in Windows I get this following message in the console:
1> Copying files to the remote machine.
1> Starting copying files to remote machine.
1> Finished copying files (elapsed time 00h:00m:00s:650ms).
1> CMake generation started for configuration: 'macos-debug'.
1> Found cmake executable at /Users/maria/.vs/cmake/bin/cmake.
1> The remote system does not have CMake 3.8 or greater. An infobar to automatically deploy CMake to the remote system will be displayed if you are building on a supported architecture. See https://aka.ms/linuxcmakeconfig for more info.
It also shows the following message above:
Supported CMake version is not present on 'remote address'. Install latest CMake binaries from CMake.org? Yes No
And when I press "yes", it says that I actually have cmake installed on the remote MacOS:
1> Copying files to the remote machine.
1> Starting copying files to remote machine.
1> Finished copying files (elapsed time 00h:00m:00s:650ms).
1> CMake generation started for configuration: 'macos-debug'.
1> Found cmake executable at /Users/maria/.vs/cmake/bin/cmake.
1> The remote system does not have CMake 3.8 or greater. An infobar to automatically deploy CMake to the remote system will be displayed if you are building on a supported architecture. See https://aka.ms/linuxcmakeconfig for more info.
CMake binary deployment to the remote machine started. CMake generation will continue automatically after deployment finishes.
CMake binary deployment to the remote machine failed: Installation directory '/Users/maria/.vs/cmake' already exists.
Solution attemps
I have tried to install CMake using brew (latest version available 3.23.1) and making sure that cmake was accessible directly from the MacOS terminal (included in PATH), I also tried doing the procedure following the official guide by installing the image .dmg by copying the "CMake.app" to "/Applications" and adding it to the path using the following command:
export PATH=/Applications/CMake.app/Contents/bin:$PATH
And I even tried to install older versions of CMake (like 3.8.0 or 3.8.1) but the same thing still happened. The expected result is the same as the Microsoft guide shown here:
1> Copying files to the remote machine.
1> Starting copying files to remote machine.
1> Finished copying files (elapsed time 00h:00m:00s:650ms).
1> CMake generation started for configuration: 'macos-debug'.
1> Found cmake executable at /Applications/CMake.app/Contents/bin/cmake.
1> /Applications/CMake.app/Contents/bin/cmake -G "Ninja" DCMAKE_BUILD_TYPE_STRING="Debug" -DCMAKE_INSTALL_PREFIX
1> [CMake] -- Configuring done
1> [CMake] -- Generating done
1> [CMake] -- Build files have been written to: /Users/cti/.vs/CMakeProject90/out/build/macos-debug
1> Extracted CMake variables.
1> Extracted source files and headers.
1> Extracted code model.
1> Extracted includes paths.
1> CMake generation finished.
Does anyone know why this is happening or what could be the solution to this problem?
This seems to be a Visual Studio bug. You can keep track of it here.
Workaround
It looks like Visual Studio always looks for CMake under local folder of currently connected via SSH user (i.e. ~/.vs/cmake/bin/cmake), no matter how you installed it. Then, when Visual Studio suggests to install it:
Supported CMake version is not present on ‘192.168.1.180’. Install latest CMake binaries from CMake.org?
If you agree to do that, it actually rolls out it locally in the said folder. The binaries Visual Studio uses are broken and throws an error if you try to use it on the Mac machine locally:
$: ~/.vs/cmake/bin/cmake
zsh: exec format error: /Users/User/.vs/cmake/bin/cmake
That's why Visual Studio keeps struggling to find the working CMake binary. You can get it round by creating a symbolic link to the folder with working CMake binaries in place of the folder Visual Studio looks for them in:
$: rm -rf ~/.vs/cmake/bin
$: ln -s /Applications/CMake.app/Contents/bin ~/.vs/cmake/bin
At this point Visual Studio will be able to locate the CMake, but won't be able to locate the default compilers and generators:
1> /Users/User/.vs/cmake/bin/cmake -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="/Users/User/.vs/CrossPlatform/out/install/macos-debug" /Users/User/.vs/CrossPlatform/CMakeLists.txt;
1> [CMake] CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
1> [CMake] CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
1> [CMake] CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
The simplest way to fix that is just by running this command on the Mac machine. It will generate the cache Visual Studio can use then, however be advised that whenever this cache is invalidated for whatever reason (e.g. when switching between configurations), you will have to re-generate it again the same way. Another option is to specify all missing parameters explicitly (either via CMakeLists.txt or as command line arguments under cacheVariables property of CMakePresets.json)
I have finally solved the problem, I had to copy the files located within the CMake application: /Applications/CMake.app/Contents/bin/cmake to the location where Visual Studio was trying to find them, which in my case was: /Users/maria/.vs/cmake/bin/cmake
The version was not a problem since I tried it with the latest CMake version (3.23.1) and it worked. Finally I found a problem related to the lack of indication of the locations of the compilers for C++ and C for CMake and the location of Ninja, I simply specified it inside CMakePresets.json and I had no major problems:
{
"name": "macos-debug",
"displayName": "macOS Debug",
"generator": "Ninja",
"binaryDir": "${sourceDir}/out/build/${presetName}",
"installDir": "${sourceDir}/out/install/${presetName}",
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Debug",
"CMAKE_C_COMPILER": "/usr/bin/gcc",
"CMAKE_CXX_COMPILER": "/usr/bin/g++",
"CMAKE_MAKE_PROGRAM": "/usr/local/bin/ninja"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Darwin"
},
"vendor": {
"microsoft.com/VisualStudioRemoteSettings/CMake/1.0": {
"sourceDir": "$env{HOME}/.vs/$ms{projectDirName}"
}
}
}
I hope someone will find this a helpful solution when developing on MacOS with Visual Studio (on Windows)
I'm trying to use CMake to build a Universal Windows App, but I get the following build error (latest Visual Studio 2019 and Windows 10 SDK are installed):
› cmake -B. -H<my source dir> -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.
CMake Error at CMakeLists.txt:3 (project):
Failed to run MSBuild command:
C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe
to get the value of VCTargetsPath:
Microsoft (R) Build Engine version 16.5.1+4616136f8 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 5/16/2020 9:52:00 PM.
Project "C:\test\CMakeFiles\3.17.2\VCTargetsPath.vcxproj" on node 1 (default targets).
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(777,5): error : The OutputPath property is not set for project 'VCTargetsPath.vcxproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='x64'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [C:\test\CMakeFiles\3.17.2\VCTargetsPath.vcxproj]
Done Building Project "C:\test\CMakeFiles\3.17.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\test\CMakeFiles\3.17.2\VCTargetsPath.vcxproj" (default target) (1) ->
(_CheckForInvalidConfigurationAndPlatform target) ->
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(777,5): error : The OutputPath property is not set for project 'VCTargetsPath.vcxproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='x64'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [C:\test\CMakeFiles\3.17.2\VCTargetsPath.vcxproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.07
Exit code: 1
-- Configuring incomplete, errors occurred!
What does that mean? I've also tried to specify the exact Windows SDK version for CMAKE_SYSTEM_VERSION, but no luck.
I solved the problem. I did many things, therefore I cannot tell which one exactly solved the problem. But try the following.
From VisualStudio Installer app, click Modify and install C++ Universal Windows Platform support for v142 build tools (ARM64) individual component.
I'm currently testing the Visual Studio 2017 RC CMake support for Android NDK C++ projects on Windows and encountered an issue.
When I try to generate the CMake cache with:
<cmake.exe> -G "Visual Studio 15 2017" -DCMAKE_INSTALL_PREFIX:PATH=<install_path> -DCMAKE_TOOLCHAIN_FILE="<androidNDK_path>\build\cmake\android.toolchain.cmake" -DANDROID_TOOLCHAIN=gcc -DANDROID_ABI="armeabi-v7a with NEON" --DCMAKE_BUILD_TYPE="Debug" <source>
I get the following error (The same happens with clang if I don't force gcc):
The C compiler "<androidNDK_path>/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe" is not able to compile a simple test program.
Before that I get the warnings that the identification of the C and CXX compilers are unknown but I'm not sure that's relevant.
I get more errors for the temporary test project but they don't seem to give a lot of information like
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Platform.targets(57,5):
error MSB4018: The "VCMessage" task failed unexpectedly.
and
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Platform.targets(57,5):
error MSB4018: System.FormatException: Index (zero based) must be greater
than or equal to zero and less than the size of the argument list.
How could I troubleshoot this?
For everybody who finds this post and has the same issue: the problem seems to be the Visual Studio generator. Also it seems like the Android toolchains requires an argument with the path to "make". So to solve both I installed MSYS (http://www.mingw.org/wiki/MSYS) and changed the CMake command to:
<cmake.exe> -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=<install_path> -DCMAKE_TOOLCHAIN_FILE="<androidNDK_path>\build\cmake\android.toolchain.cmake" -DCMAKE_MAKE_PROGRAM="<MinGW_path>\msys\1.0\bin\make.exe" -DANDROID_TOOLCHAIN=gcc -DANDROID_ABI="armeabi-v7a with NEON" --DCMAKE_BUILD_TYPE="Debug" <source>
I have build a Qt project (qwt) using the vs2013 compiler in Qt creator. When I open the .pro file and look at the build steps I see:
qmake: qmake.exe qwt.pro -r -spec win32-msvc2013
Make: nmake.exe in C:\qwt-6.1.2
When I build the project, all goes fine and the project is build without errors. So far so good.
However when I try to build this project using the command line I get errors during the nmake step. I have used the same commands as above (and I'm sure that I'm using the same versions of qmake/nmake).
...\QtCore\qglobal.h(38) : fatal error C1083: Cannot open include
file: 'stddef.h': No such file or directory
My question is, what does Qt do more so that the project does build in Qt creator and not from the command prompt? And how can I copy this behaviour in the command prompt? I'm doing this so I can make a batch file that builds the project (on a machine that does not have Qt creator installed).
In order to use the Visual Studio compilation environment from the command-line you need to call the vcvars batch script to set up the paths correctly.
Either call the vcvars64.bat in the C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64 folder (that is for VS2013, you can replace the "12.0" with whatever visual studio version you have).
Or the vcvars32.bat in the C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin folder.
Or use the vcvarsall.bat x86 or vcvarsall.bat x64 calls for the script in C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC
Alternatively Visual Studio creates shortcuts in the start-menu called along the lines of VS2013 x64 Native Tools Command Prompt which call those scripts.
It's likely to be that Qt Creator has added additional variables into the build environment, which are not presented when you try to compile manually through cmd.
If you look within Qt Creator under the Projects section there's Build information. Expand the Build Environment information and check to see if there's anything in there different to your machines global environment settings.
How can I get Visual Studio 2012 to use the native amd64 toolchain, rather than the default x86_amd64 cross-compiler?
I am building a large library that causes the linker to run out of memory when doing whole program optimization and link-time code generation.
I found two older posts (here and here) asking this same question, but no answers yet. Microsoft provides documentation on how to specify the toolchain on the command line, but not in the IDE.
There is another method of forcing use of the 64-bit linker on a per-project basis for Visual Studio 2013. Edit your .vcxproj file and insert the following after the <Import...Microsoft.Cpp.Defaults line:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup>
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
</PropertyGroup>
You need to set the environment variable "_IsNativeEnvironment" to "true" prior to starting Visual Studio 2012 IDE:
set _IsNativeEnvironment=true
start "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" your_solution.sln
For Visual Studio 2013, the name of the environment variable is different:
set PreferredToolArchitecture=x64
sbm start "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" your_solution.sln
Beware that this technique does not work if the version of the IDE does not match the version of the toolchain. That is, if you use VS2013 IDE configured to run VS2012 compiler, you are out of luck. But such combination is uncommon.
Here are some links for further information:
difference between VS12 and VS13
how to embed PreferredToolArchitecture into the project in VS13
If your goal is to use the native environment rather than specifically amd64_x86, you can set the UseNativeEnvironment property in your project file:
<PropertyGroup>
<UseNativeEnvironment>true</UseNativeEnvironment>
</PropertyGroup>
(I have successfully added it to the "Globals" PropertyGroup.)
You can check which toolchain is being used by adding the /Bv compiler option. Example output is below. Notice that the toolchain directory appears after bin\ (amd64_x86 in this case).
2>ClCompile:
2> Compiler Passes:
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\CL.exe: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1xx.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c2.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\link.exe: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\mspdb120.dll: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\1033\clui.dll: Version 18.00.31101.0
I know this is a rather old post, but it's still relevant for VS 2017. Here you also have the "PreferredToolArchitecture" environment variable and a "build in" setting in the IDE is not readily available.
However you can integrate that easily on a project by project base so that you can always chose what tool architecture to use. Maybe this is helpful for some. Do this:
Go to Property Manager and create a new property sheet, e. g. named "x64 Toolchain.props" so you know what it does. With a separate property sheet you can then switch the tool architecture as appropriate by including or not including the sheet into a project.
Open the properties of that new sheet, navigate to "Common Properties\User Macros" and click "Add Macro".
In the dialog you set the name to "PreferredToolArchitecture", the value to "x64" and enable the checkbox "Set this macro as an environment variable in the build environment".
Optionally navigate to "Common Properties\C/C++\Command Line" and add "/Bv" under "Additional Options". This will make the compiler output the tools it uses including its path and version number, might be helpful for checking if really the desired architecture is being used. It will place entries in the log output window like so:
Compiler Passes:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1xx.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c2.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\link.exe: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\mspdb140.dll: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\1033\clui.dll: Version 19.15.26730.0
Now for all projects that should be build with the x64 tool architecture include the new property sheet into the project in property manager. And for those that should not simply don't include it. That's it.
HTH
Edit:
It seems unfortunately this is not reliable! See below comments. I would really appreciate if MS would wire this setting to some GUI element and make it work consinstently...
I have a similar problem using Visual Studio 2010 on XP 64 SP2. If I set the VC++ executable directory to the amd64 bin (the native x64 folder) as the first in the search path, then I received the TRK0002 error … Invalid handle value.
But if I set _IsNativeEnvironment=true in a Visual Studio 2010 command prompt and start the ide from the command line as posted before, then the error goes away. Apparently, the 32-bit GUI IDE Environment is receiving info from a 64 bit process and is expecting info from a 32-bit process such as x86\cl.exe or x86_64\cl.exe.
In a scenario where you want to compile an IA64 bit executable, and you use the x86_ia64\cl.exe compiler. Since you are using a 32-bit cross compiler and have the _IsNativeEnvironment variable set to true, this must upset the IDE when posting messages in it's window consoles. Set the _IsNativeEnvironment=false, if you have previously set it to true.
The IDE should pick up that a native compiler was being used on a native 64-bit
machine and should have automatically set this variable to the appropriate value when the native compiler was selected from the IDE. A simple fix has never been applied to patch this problem. Solution. Do it yourself from the prompt, or buy the latest IDE from Microsoft to fix the problem.
So, the real wizards at Microsoft are the developers who work mainly from the command line. And the other developers, who wear the pointy hats and sit in the corner, must have been hired from Apple and were more concerned about appearance than function.
The whole purpose of an IDE is to make coding simple, not more complicated than using a text editor and a Makefile from the command line.