I have the Intel compiler platform install on my development machine, when using Cmake to generate a visual studio 2010 solution, I want to be able to specify the platform toolset to be using "Intel" instead of "vc100".
I cant seem to find the setting to change this, when I change the compiler to icl the solution still builds with the vc100 compiler until I manually change the platform toolset.
I was looking for similar functionality as well, for setting the Windows SDK 7.1 as the default toolset for a large number of projects, without having to go through and change each one by hand.
I believe that the CMAKE people have added that functionality, and you can use something like:
set_target_properties(${YOUR TARGET} PROPERTIES PLATFORM_TOOLSET "Intel C++ Compiler XE 12.1")
Have a look at:
http://public.kitware.com/Bug/view.php?id=12876
for details of the change.
I was able to change the platform toolset by using a command-line option (CMake 3.2):
cmake . -G "Visual Studio 12" -T "LLVM-vs2013"
Related
I have downloaded an installed LLVM 10 on Win 10 machine, which already had VS2019-Enterprise.
Created the Directory.build.props file as:
<Project>
<PropertyGroup>
<LLVMInstallDir>full_path_to_my_llvm</LLVMInstallDir>
</PropertyGroup>
</Project>
Ran MSBuild while on the directory that contains .sln and .vxproj files.
Still cannot get see llvm under ConfigurationProperties->General->PlatformToolset.
How does one add LLVM to VS2019?
You can use the Clang Power Tools extension to add any custom LLVM versions, starting with LLVM 4, directly from Visual Studio. (Disclaimer: I am the author of this extension.)
Go to CPT Settings -> select the LLVM Tab -> select the version you want to install by clicking the install button. No configuration is needed. Here is an article about this feature.
You can install multiple versions and decide later what version is better for you.
I just ran into the same issue myself, so I'll post the solution since I came across this question while searching for an answer.
Clang/LLVM support in Visual Studio projects
For best IDE support in Visual Studio, we recommend using the latest Clang compiler tools for Windows. If you don't already have those, you can install them by opening the Visual Studio Installer and choosing C++ Clang tools for Windows under Desktop development with C++ optional components. If you prefer to use an existing Clang installation on your machine, choose the "C++ Clang-cl for v142 build tools." optional component.
C++ Clang-cl for v142 build tools (MSDN's image)
All you have to do is install the 2nd component as shown. After you install that component, and load up Visual Studio again, you'll be able to select "LLVM (clang-cl)" from the Platform Toolset option.
That's all there was to it!
I need to build a dependency that uses SCons, and I need to build it with VC++2017, because another dependency I have cannot be built with VC++2019.
SCons successfully detects VC++2019 (v14.2), but not VC++2017 (v14.1):
c:\Python27\Scripts\scons [...] --msvc-version=14.1 [...]
scons: Reading SConscript files ...
scons version: 3.1.1
python version: 2 7 13 'final' 0
scons: warning: VC version 14.1 not installed. C/C++ compilers are most likely not set correctly.
Installed versions are: ['14.2', '14.0', '11.0']
[...]
C++ compiler $CC does not work
I have installed Visual Studio 2019 Enterprise as well as Visual Studio 2019 Build Tools, and for both, I have installed the platform tools / compiler for v14.1 and x86/x64. Compiling with the VC++2017 platform tools works fine in Visual Studio 2019 as well as using MSBuild, so the problem seems to be with SCons only.
How does SCons detect VC++2017 and VC++2019 and where should I start looking for the problem?
(There are old threads about this, but most of them are about people wondering why the "classic" detection/config methods using registry and vcvars.bat no longer work, so these are not helpful)
For current scons, it will believe what it gets back from vswhere.exe for the versions where that tool is considered definitive - 2017 and 2019. You can try seeing what that gives you.
vswhere -products * -property installationPath
That information is used to help locate the desired vars.bat file which imports the seetings needed.
I have found a perfect and simple solution:
Open file MSCommon/vc.py, find line: vc_pdir = os.path.join(vsdir[0], 'VC')
Change [0] to [1]
Re-build, the python will use vs2017
The reason is: if you install multi vs versions, the vsdir[0] is the highest one
Update: This is still (2021-09-16) an issue, and a simple workaround may be this answer - My answer also has a workaround, but it is more complicated and mostly for educational purposes on how recent versions of VC++ compilers can be detected and are (not properly) detected by SCons. You may also want to use my workaround if you are creating a build script for a build server or multiple development machines with varying setups.
The current version of SCons does not support selecting MSVC v14.1 (aka "Visual C++ 2017") if Visual Studio 2019 is installed, but Visual Studio 2017 is not. I confirmed this by looking at the code of SCons (see below).
An alternative approach is to use the --msvc-script option instead of --msvc-version.
In the MSVC installation folder, typically c:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\, you will find a file called vcvarsall.bat. If you run this without arguments, you will see that you can give it arguments for target platform and tools version, e.g.,
vcvarsall.bat x86 10.0.17763.0 -vcvars_ver=14.1
to compile for x86 (32-bit), Windows SDK version 10.0.17763.0 and tools version 14.1 (Visual C++ 2017).
Once you have found a command line for vcvarsall.bat that suits you, put it into a new BAT file that you create, say myvcconfig.bat (You have to use the complete path to vcvarsall.bat), then use the following command-line switch to SCons: --msvc-script=myvcconfig.bat.
*** Notes ***
Some parameters to SCons are redundant and will not work with --msvc-script, for example --32. SCons will tell you about them, so just remove them from the command-line.
The installation path of Visual Studio may be different from the one I provided above. You can find the installation path using Microsoft's own VSWhere tool. See also Locate Visual Studio
Visual Studio 2019 and Visual Studio Build Tools 2019 are separate installations with separate build tools. You can detect and use the vcvarsall.bat files of either ones. For example, if you are setting up a toolchain for a build server, you may want to use Visual Studio Build Tools 2019. If you just want to build one library one time (as in my case), just use the Visual Studio that is installed on your dev machine.
In case you are interested in how SCons detects MSVC and why it doesn't work, you can look at the source code in SCons/Tool/MSCommon/vc.py. You can clone the SCons GIT repository.
UPDATE: The following comment in vc.py (as of 2021-09-16) shows why this is still an issue in SCons and why this workaround is needed if you have both VC2017 and VC2019 compilers installed:
# make sure the cl.exe exists meaning the tool is installed
if ver_num > 14:
# 2017 and newer allowed multiple versions of the VC toolset to be
# installed at the same time. This changes the layout.
# Just get the default tool version for now
#TODO: support setting a specific minor VC version
Direct link (valid at time of writing)
How can I force Cmake to use Visual Studio 2010 for compiling my emscripten projects, and now VS 2015?
I keep running into an issue where cmake says it cannot find the build tools for MSBuild v140. I know it exists though, as the file path is
C:\Program Files (x86)\MSBuild\14.0\Bin
I've even tried setting the path in the Emscripten Command Prompt with
set PATH=C:\Program Files (x86)\MSBuild\14.0\Bin;%PATH%
but the issue still occurs.
If I open this solution in VS 2015, I can see that the configuration is set to Msbuild v 1.40, so I can't wrap my head around why Emscripten says it can't locate it.
The closest thing I could find is in this GitHub bug report on Emscripten.
Any suggestions?
Emscripten in Visual Studio is only supported for VS2010 AFAIK. Personally, I suggest you work with makefiles when generating from CMake. It is much more stable from my experience. The Visual Studio support for Emscripten is not working well, at least for me.
But if you still want to use VS2010, then you have to set the CMake generator to "Visual Studio 10 2010", and then specify the Emscripten toolchain file. You might have to set the CMake platform name to Emscripten, using the -A argument.
cmake.exe -G "Visual Studio 10 2010" -A Emscripten -DCMAKE_TOOLCHAIN_FILE=%EMSCRIPTEN%\cmake\Modules\Platform\Emscripten.cmake
I tried doing this, but each time I did, Emscripten would return a different path to Emscripten.cmake, and say it couldn't find it. Not sure where it was getting this new path from.
Long story short, I realized I installed the web installer for Emscripten installed. So I uninstalled that and instead went with the Full installer, and it all worked well.
I have built the LLVM using Cmake from the documentation # LLVM on visual studio. I have an existing code project in visual studio, where I want to build my interpretor. I want to set the Platform Toolset to LLVM, however when I navigate to Properties>general>Platform Toolset in VS 2012 for my existing project, I dont see an option to add the LLVM tool chain in the drop down. I must be doing something terribly wrong here. Any help would be appreciated.
The LLVM Platform Toolset is not built by default- it requires a custom installation step and is not as simple as "Just build LLVM". Typically, it's easier to just download the installer from the LLVM Website. If you want to know how to build the Windows installer yourself, you'll have to ask in #llvm on OFTC.net.
Note that the existing LLVM Platform Toolset solution has some serious integration limits, like no exceptions/RTTI and AFAIK no support for the debugger and such too, which makes it seriously limited. Right now it's mostly useful for getting better error messages.
With Visual Studio 2012 Update 1 released, I am hoping to build a C++ project to support Windows XP. Is there a way to use CMake to generate a project that targets Windows XP? Basically CMake would need to generate a project file that uses Platform Toolset = Visual Studio 2012 - Windows XP (v110_xp).
According to http://www.cmake.org/Bug/view.php?id=10722 the answer is now (soon) yes.
Fixed in Version CMake 2.8.11
A new "generator toolset" feature has been added here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dab9977 [^]
One may now run CMake from the command line with
-G "Visual Studio 10" -T "v90"
in order to build with a specific toolset. We've not yet added a
first-class interface to cmake-gui for this, but one may add the cache
entry "CMAKE_GENERATOR_TOOLSET" to contain the "-T" value before
configuring.
According to http://www.cmake.org/Bug/view.php?id=10722 the answer is no yes.
Update: The bug mentioned above has been resolved with the following comment:
Fixed in Version CMake 2.8.11
A new "generator toolset" feature has been added here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dab9977 [^]
One may now run CMake from the command line with
-G "Visual Studio 10" -T "v90"
in order to build with a specific toolset. We've not yet added a
first-class interface to cmake-gui for this, but one may add the cache
entry "CMAKE_GENERATOR_TOOLSET" to contain the "-T" value before
configuring.
You might also look at the comments made to the other answers.
I think you can just generate a Solution for Visual Studio 2010/2012. Open this solution, open the solution/project in visual Studio, open the properties and reconfigure the Platform toolset to v110_xp.
Then you should be fine. But I'm still searching for the solution how to setupo the command line to build v110_xp programs...
I think the best way to address this problem is use CMake to build your project for Visual Studio 2010 and then open the project with Visual Studio 2012. When you do this the toolset used will be vs2010, which works for WinXP.