I'm using cmake to build the project.
There is a CMakeLists where is used to build the project.
So, when I create a build folder, and use
cmake ..
the project solution is created, but with MVSC c++ compiler.
Is it possible to generate a solution with GCC compiler but in a Visual studio solution?
How can I detect in CMakeLists.txt, that Visual Studio Clang toolset is used, as opposed to clang on Linux? When Visual Studio Clang toolset is used, I need to specify extra flags specific to Visual Studio headers (such as _CRT_SECURE_NO_WARNINGS).
Further info:
The toolset is Visual Studio Community 2019 Preview, version 16.10.0 Preview 3.0 (with C++ Clang Tools for Windows 10.0.0).
To build I am using Visual Studio Codium 1.56.2 with plugins CMake 0.0.17 and CMake Tools 1.7.2.
The VSCode CMake plugin autodetects Visual Studio Clang toolset, and when I select it, it builds with following command:
D:\dev_tools\cmake\bin\cmake.EXE --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\Llvm\x64\bin\clang.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\Llvm\x64\bin\clang.exe" -Hd:/dev/exemine -Bd:/dev/exemine/build -G Ninja
The build works correctly. I just need to detect when this toolset is used from CMakeLists.txt and specify few extra options.
Note: As a workaround, I am using following code:
if(MSVC OR (CMAKE_CXX_COMPILER MATCHES "clang.exe$"))
add_compile_definitions(WIN32)
...
The official LLVM 4.0 build for Windows integrates with Visual Studio up to Visual Studio 2015. Unfortunately it still doesn't support Visual Studio 2017.
When you try to set the Platform Toolset of a project to LLVM-vs2014, it pops up an error.
Do you know any way to make it work?
Update
In 2018, LLVM 6.0 officially still doesn't support integration with Visual Studio 2017 (version 15.X.X), only with the Visual Studio 2015 (version 14.X.X) toolset.
It requires some msbuild targets that only ship with the C++ v140 toolset, and VS 2017 only installs the v141 toolset by default. If you open the VS 2017 installer, find the checkbox for the v140 toolset and install that then the right C++ msbuild targets will be available and the thing will work.
Finally, I found a brilliant GitHub repo with the required MSBuild platform toolsets which integrates LLVM clang 5.0.0 into Visual Studio 2017. After following the instructions of the README file, you will have two new platform toolsets LLVM-vs2017 and LLVM-vs2017_xp. Problem solved.
Update
I made a fork which is updated for LLVM 6.0.0 and provides better integration by providing include and library paths of LLVM/clang.
Thanks to Royi, who realized that the original .prop files are explicitly tailored for LLVM 5.0 and it misses adding the proper lib (
$(LLVMInstallDir)\lib) and include ($(LLVMInstallDir)\lib\clang\6.0.0\include) folders.
The LLVM project now explicitly supports Visual Studio 2017 via https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain
I'm a newbie with the LLVM technology and I'm using a Visual Studio extension, Clang Power Tools. They have a settings page from where you can install LLVM (all versions >= 4.0). After that you are free to apply clang compile or tidy with code modernization(this is what I appreciate the most) by using the extension buttons from VS toolbar. In this way you don't need to configure anything.
Update
Open the extension settings and select the LLVM page from the top. On the LLVM page, you'll see all the supported LLVM versions and at the right of each version the install button. Install any version you need. On the bottom of the page is a dropdown that allows you to select what version to use in case you installed multiple versions.
The feature is explained step by step in this blog post
LLVM/Clang now has an updated patch that allows you to use it with VS2017. But they still don't directly support VS2017. I asked on the LLVM developer mailing list for them to update their support for VS2017, so hopefully they'll do it. If they listen to what I said.
I have figured out how to integrate LLVM Clang 7.0 with Visual Studio 2017 update 15.5.6. v1913 with full support for PDB based debugging using the latest LLVM builds.
i.e., lld-link /DEBUG:GHASH; clang-cl -mllvm -emit-codeview-ghash-section flag to clang-cl.
It is a three step process.
Install latest llvm
Update the toolset.props, toolset.targets in VS to support latest clang
Select the new toolset to use for building your C/C++ or other lang project
As of Visual Studio 2017 update 15.4.5 the Microsoft "experimental" Clang C2 no longer works. Thus, the above fixes are necessary to use clang to compile code that has full PDB (not just CodeView /Z7 limited) debuggability. This also now becomes a more complete suite for portability testing cross-platform builds since you can build and PDB debug for windows using all LLVM components from the clang compiler front end to the LLVM codegen backend and LLVM linker.
Cheers, David
Check out January 09, 2018 http://planet.clang.org/
Look at the "Try it out!" section:
If you're already using clang-cl and lld-link on Windows today, you can try this out. There are two flags needed to enable this, one for the compiler and one for the linker:
To enable the emission of a .debug$H section by the compiler, you will need to pass the undocumented -mllvm -emit-codeview-ghash-section flag to clang-cl (this flag should go away in the future, once this is considered stable and good enough to be turned on by default).
To tell lld-link to use this information, you will need to pass the /DEBUG:GHASH to lld.
You just need to pass the -mllvm -emit-codeview-ghash-section flags in either your c++ projects "Command Line:Additional Options" area, or place them directly in the "toolset.props" file that you created in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\LLVM-vs2017 or
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Platforms\x64\PlatformToolsets\LLVM-vs2017.
The key is that in adding those cli options you're telling clang to emit debug information that the lld (aka lld-link) will understand and use to produce fully populated PDB files. Not the limited ones it made prior to the Jan 09, 2018 drops of LLVM 7.0.
toolset.targets: (any version)
<Project ToolsVersion="14.1"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
</Project>
toolset.props: (Win32 version)
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Microsoft.Cpp.$(Platform).v141.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Microsoft.Cpp.$(Platform).v141.props')"/>
<Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Toolset.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Toolset.props')"/>
<PropertyGroup>
<LLVMInstallDir>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\LLVM\LLVM)</LLVMInstallDir>
<LLVMInstallDir Condition="'$(LLVMInstallDir)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LLVM\LLVM)</LLVMInstallDir>
<ExecutablePath>$(LLVMInstallDir)\msbuild-bin;$(ExecutablePath)</ExecutablePath>
<LibraryPath>$(LLVMInstallDir)\lib\clang\7.0\lib\windows;$(LibraryPath)</LibraryPath>
</PropertyGroup>
<ItemDefinitionGroup>
<ClCompile>
<!-- remove the implicit vcxxx.pdb path to avoid rebuilds every time as clang-cl only supports /Z7 -->
<ProgramDataBaseFileName></ProgramDataBaseFileName>
<!-- Set the value of _MSC_VER to claim for compatibility -->
<AdditionalOptions>-m32 -fmsc-version=1913 %(AdditionalOptions)</AdditionalOptions>
</ClCompile>
</ItemDefinitionGroup>
</Project>
For x64, change -m32 to -m64
p.p.s., I have also enabled Microsofts ARM and ARM64 compilers for building native Windows-10-ARM apps (not UWP modern-com-junk). But, as yet, I have not done enough digging through the clang sources to properly configure something similar for ARM to what -m32 and -m64 do for Intel code-gen.
See these articles:
http://pete.akeo.ie/2017/05/compiling-desktop-arm-applications-with.html
https://www.theverge.com/2017/12/5/16737288/microsoft-windows-10-qualcomm-arm-laptops-launch
https://wiki.winehq.org/ARM
Currently, in order to create static libs on windows, you manually have to specify where the Visual Studio directory is.
cmake -G "MinGW Makefiles" -DCMAKE_C_COMPILER=gcc -DCMAKE_GNUtoMS=1 -DCMAKE_GNUtoMS_VCVARS="C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" ..
Is there a way for CMake to automatically query for the location of Visual Studio? The Windows-GNU.cmake module seems to be able to query the registry for the location of the lib.exe executable, but still forces the user to manually specify it's location. An excerpt from cmake:
find_program(CMAKE_GNUtoMS_VCVARS NAMES vcvars32.bat
DOC "Visual Studio vcvars32.bat"
PATHS
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\12.0\\Setup\\VC;ProductDir]/bin" #D
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0\\Setup\\VC;ProductDir]/bin"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\10.0\\Setup\\VC;ProductDir]/bin"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\9.0\\Setup\\VC;ProductDir]/bin"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\8.0\\Setup\\VC;ProductDir]/bin"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\7.1\\Setup\\VC;ProductDir]/bin"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\6.0\\Setup\\Microsoft Visual C++;ProductDir]/bin"
)
The above is from cmake 3.6.0.
If building a static library is your primary concern, have you tried setting
-DBUILD_SHARED_LIBS=OFF
or similar (e.g. add_library with STATIC) to force static build?
I have downloaded and installed CUDA 6.5 on windows 7 with visual studio 2010.
Let us say I build a sample CUDA code from SDK (visual studio 2010).
How do I know which compiler I am using?
Also how do I make sure that the CUDA Toolkit that I am using to compile my CUDA C
code must support the following switch for generating debug symbolics: -G0
This is mentioned here and quoted below:
CUDA Toolkit: In order to use a project with the NVIDIA Nsight tools,
we recommend that you use the compiler that ships with the tools. The
default installation directory for this version of the compiler is:
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA
The compiler is in a subdirectory labeled by its version, such as:
...\\bin\nvcc.exe
The NVIDIA Nsight tools work best with this version of the compiler.
However, the tools also work with the standard toolkit. Whichever
compiler you use, the CUDA Toolkit that you use to compile your CUDA C
code must support the following switch for generating debug symbolics:
-G0
The note that you are referencing is old and should be updated.
The Visual Studio C++ build system is extended to support CUDA by inclusion of a CUDA props file in the vcxproj. For example in the 6.5 samples you should find the sections
<PropertyGroup>
<CUDAPropsPath Condition="'$(CUDAPropsPath)'==''">$(VCTargetsPath)\BuildCustomizations</CUDAPropsPath>
</PropertyGroup>
<ImportGroup Label="ExtensionSettings">
<Import Project="$(CUDAPropsPath)\CUDA 6.5.props" />
</ImportGroup>
<ImportGroup Label="ExtensionTargets">
<Import Project="$(CUDAPropsPath)\CUDA 6.5.targets" />
</ImportGroup>
The default location for VCTargetsPath is
c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0[VSver]\BuildCustomizations
If you open the "CUDA 6.5.props" file you can see how the location of the toolkit is determined.
<PropertyGroup>
<!-- Check CUDA Toolkit versioned environment variable. -->
<CudaToolkitDir Condition="'$(CudaToolkitDir)' == ''">$(CUDA_PATH_V6_5)</CudaToolkitDir>
<!-- Last, check the new CUDA Toolkit style/Nsight toolkit registry value. -->
<CudaToolkitDir Condition="'$(CudaToolkitDir)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\NVIDIA Corporation\GPU Computing Toolkit\Cuda\$(CudaToolkitVersion)', 'InstallDir', null, RegistryView.Registry64, RegistryView.Registry32))</CudaToolkitDir>
<!-- Ensure $(CudaToolkitDir) has a trailing backslash. -->
<CudaToolkitDir Condition="'$(CudaToolkitDir)' != '' AND !HasTrailingSlash('$(CudaToolkitDir)')">$(CudaToolkitDir)\</CudaToolkitDir>
<CudaToolkitIncludeDir Condition="'$(CudaToolkitIncludeDir)' == ''">$(CudaToolkitDir)include</CudaToolkitIncludeDir>
</PropertyGroup>
Switching Toolkits in VXCPROJ
In the vcxproj modify the version number in the CUDA .{props, targets} lines and reload the project.
Switching Toolkits in VS
In Visual Studio open Solution Explorer.
In Solution Explorer right click on the project node and execute "Build Customization"
In the Visual C++ Build Customization Files check the correct target.
Overriding the Toolkit Location
If you have a version of the CUDA toolkit that was not installed using the installer you can override the default locations by
a. Set the toolkit environment variable. For example, set CUDA_PATH_V6_5, or
b. Override the setting for CudaToolkitDir in the vcxproj, or
c. In VS in the Property Page for the project change CUDA C/C++ | CUDA Toolkit Custom Dir.