Visual Studio CMake Support – Clang/LLVM, CMake 3.14, Vcpkg, and Performance Improvements

Will Buik

April 24th, 20194 0

We’ve introduced a bunch of improvements to our CMake support in the latest preview of Visual Studio 2019 Update 1. The latest release includes Clang/LLVM support, CMake 3.14, better vcpkg integration, and many more enhancements. If you are not familiar with Visual Studio’s CMake support, check out how to get started.

Clang/LLVM Support

Visual Studio now supports Clang/LLVM for CMake projects and you can now use Clang to target Windows and remote Linux machines. Full IntelliSense is supported along with Visual Studio’s comprehensive debugging support. Check out our Clang/LLVM post for much more information.

CMake 3.14 with Performance Improvements and Visual Studio 2019 Generator

We’ve updated the version of CMake that ships with Visual Studio to 3.14. This version includes the latest MSBuild generators that support Visual Studio 2019. You can learn more about what’s new in CMake 3.14 in CMake’s release notes.

Microsoft also worked with the CMake community to bring a new way of interfacing IDEs with CMake in 3.14 that replaces CMake server mode. What this means for you, is that many CMake operations (especially configuration) will be faster from now on. If you are interested in learning more about this, we are going to be writing a whole post about this soon.

Better Vcpkg Integration

In our first release of Visual Studio 2019 we introduced basic integration with vcpkg. In the latest preview we have enhanced with better integration with IntelliSense. Now, when you are adding a header for a missing library, we will recommend how to install it with vcpkg if it is available. There is also now IntelliSense for CMake’s “find_package” directive:

Simpler CMake Build and Install Roots

With Visual Studio 2019 version 16.1 Preview 2 we have updated the default build and install roots for local and remote CMake projects to be more in-line with the standard set by open-source CMake projects. When you create a new CMake project in Visual Studio using the “CMake Project” template, or add a new configuration to an existing project, the following build and install roots will be used. You can change these properties at any time by modifying the “Build root” and “Install root” (or “Remote build root” and “Remote install root”) properties of the CMake Settings Editor.

Local CMake Projects:

Build root: ${projectDir}\\out\\build\\${name} Install root: ${projectDir}\\out\\install\\${name}

Remote CMake Projects:

Remote build root: $HOME/.vs/${projectDirName}/${workspaceHash}/out/build/${name} Remote install root: $HOME/.vs/${projectDirName}/${workspaceHash}/out/install/${name}

All of the macros used in CMakeSettings.json can be referenced here. In these file paths:

${projectDir} is the full path to the folder of the root CMakeLists.txt file
${name} is the name of the configuration
${projectDirName} is the name of the root directory (similar to ${projectDir} but omits the rest of the path)
${workspaceHash} is a hash of the workspace location. It is used because project names are not guaranteed to be unique across directories.

These changes also resolve an issue with the old default build/install roots for Linux projects where you would see a mkdir failure if there was no write access to the folder (/var/tmp/…).

Changes to the Default CMake Configuration

Previously, new CMake projects in Visual Studio would create a default configuration that was never saved to disc. Now Visual Studio will create a default “x64-Debug” or “x86-Debug” configuration that matches the bitness of your machine and persists like a normal configuration.

Enhanced Customizability for Importing Existing Caches

We’ve added a new way to customize how existing caches are imported into Visual Studio. Previously, the IDE would re-run CMake with its initial settings to refresh the cache and build tree if you made changes to the CMake projects. You can now replace that behavior with any custom script or executable that drives the recreation of the CMake cache. If your project drives CMake with external scripts or custom tools, you can now fully integrate it with the IDE. Edit, build, and debug your complex codebases without having to leave the IDE and go back to the command line.

To use this feature, just set “cacheGenerationCommand” to the command line of your script or tool in your CMakeSettings.json file:

Logging for Remote Connections in Visual Studio

With Visual Studio 2019 you can develop C++ for both Linux and Windows from the comfort of a single IDE. In Visual Studio 2019 version 16.1 Preview 2 we have added logging for SSH connections to remote systems. This makes it easier to diagnose issues with remote connections and provides full transparency into what commands are being executed on your remote machine. Logs include connections, all commands sent to the remote machine (their text, exit code and execution time), and writes from Visual Studio to the shell.

Logging works for any cross-platform CMake project or MSBuild based Linux project in Visual Studio. To enable logging, navigate to Tools > Options > Cross Platform > Logging, or search for “SSH logging” in the search bar at the top of your screen.

You can configure logging to a file or to the “Cross Platform Logging” pane in the Output Window. Note that for MSBuild based Linux projects, commands issued to the remote machine by MSBuild will not get routed to the Output Window because they are emitted out-of-proc. They are, however, logged to a file with the “msbuild_” prefix.

Send Us Feedback

Your feedback is a critical part of ensuring that we can deliver the best CMake experience. We would love to know how Visual Studio 2019 version 16.1 Preview 2 is working for you. If you have any questions specific to CMake Tools, please reach out to cmake@microsoft.com or leave a comment. If you find any issues or have a suggestion, the best way to reach out to us is to Report a Problem.

Will Buik Program Manager, Visual Studio C++ IDE

4 comments

Hristo Hristov April 25, 2019 7:17 am 0

To my best knowledge CMake recommends out-of-source builds:
out/buildSource/CMakeLists.txttherefore this is promoting bad practices:
Local CMake Projects:
Build root: ${projectDir}\\out\\build\\${name}Install root: ${projectDir}\\out\\install\\${name}
Something more like this:
Local CMake Projects:
Build root: ${projectDir}\\..\\out\\build\\${name}Install root: ${projectDir}\\..\\out\\install\\${name}
It would help if VS can detect and use CMakeLists.txt in subfolders something like that:
workspaceDir projectDir1 -> CMakeLists.txt out/build1
I am also very glad about the LLVM support!!! Does this also support external clang-format, etc? It is not clear what version does VS Intaller contain? Does it even make sense to distribute it with the installer? I’d rather be able to install these third party tools – LLVM, CMake separately and to not depend on VS to update them. Although you are upgdating CMake on the regular basis that was not the case at the beginning.

Will Buik April 26, 2019 8:26 pm 0

Thanks for all the feedback!

We’re glad to hear that our LLVM support will help you. We will do our best to keep the version of Clang that we ship with Visual Studio up-to-date. It is completely optional though. You can install your own version of Clang/LLVM and use it instead of the one that is included in the installer. Check out the LLVM post for more info about how to do this: https://devblogs.microsoft.com/cppblog/clang-llvm-support-in-visual-studio/

We don’t support external clang-format yet. Please open a suggestion on Developer Community (https://docs.microsoft.com/en-us/visualstudio/ide/suggest-a-feature.)

I believe the recommendation from CMake is to keep the source tree separate from the binary tree – but I think in most cases the new defaults will do this but if you have an example project where this separation isn’t maintained please point us towards it.
- Hristo Hristov April 30, 2019 7:07 am 0
  
  “I believe the recommendation from CMake is to keep the source tree separate from the binary tree – but I think in most cases the new defaults will do this but if you have an example project where this separation isn’t maintained please point us towards it.”
  ${projectDir}\\out\\build\\${name} -> puts the \\out\\build\\${name} in the same directory where the root CMakeLists.txt file is located. IHMO this is a violation of CMake’s recommendation to keep the source tree separate from the binary tree. CMakeLists.txt is also a sort of a “source” file. \out\\build\\${name} should be out of ${projectDir} as it used to be before this update. This means when you open the folder containting CMakeLists.txt VS is going to index all the build artifacts located in \\out\\build\\${name}. When I started using VS for its CMake support I came across a problem – VS failed at indexing a source folder which contained like 30 GB of artifacts and assets. The C++ sources were probably less than 1Mb and all this happened because originally VS would put the build directory inside of the source directory by default and the authors of the projects never cared to separate them (and it wasn’t that easy anyway).

Moritz Beutel June 3, 2019 2:06 pm 0

Intellisense support for CMake files is appreciated, but I sorely miss the configurability available for other languages. (There is no “CMake” node under “Options…” | “Text Editor”.)

In particular, I’d like to disable “Auto list members”, which constantly gets in the way. Repro: Open any CMake script file, navigate to an empty line, hit Tab twice. The first Tab key opens the function list, the second Tab key inserts the element first position (`add_compile_definitions`). All I wanted was two tabs!!

Discussion is closed. Login to edit/delete existing comments.

Hristo Hristov April 25, 2019 7:17 am 0

To my best knowledge CMake recommends out-of-source builds:
out/buildSource/CMakeLists.txttherefore this is promoting bad practices:
Local CMake Projects:
Build root: ${projectDir}\\out\\build\\${name}Install root: ${projectDir}\\out\\install\\${name}
Something more like this:
Local CMake Projects:
Build root: ${projectDir}\\..\\out\\build\\${name}Install root: ${projectDir}\\..\\out\\install\\${name}
It would help if VS can detect and use CMakeLists.txt in subfolders something like that:
workspaceDir projectDir1 -> CMakeLists.txt out/build1
I am also very glad about the LLVM support!!! Does this also support external clang-format, etc? It is not clear what version does VS Intaller contain? Does it even make sense to distribute it with the installer? I’d rather be able to install these third party tools – LLVM, CMake separately and to not depend on VS to update them. Although you are upgdating CMake on the regular basis that was not the case at the beginning.
- Will Buik April 26, 2019 8:26 pm 0
  
  Thanks for all the feedback!
  
  We’re glad to hear that our LLVM support will help you. We will do our best to keep the version of Clang that we ship with Visual Studio up-to-date. It is completely optional though. You can install your own version of Clang/LLVM and use it instead of the one that is included in the installer. Check out the LLVM post for more info about how to do this: https://devblogs.microsoft.com/cppblog/clang-llvm-support-in-visual-studio/
  
  We don’t support external clang-format yet. Please open a suggestion on Developer Community (https://docs.microsoft.com/en-us/visualstudio/ide/suggest-a-feature.)
  
  I believe the recommendation from CMake is to keep the source tree separate from the binary tree – but I think in most cases the new defaults will do this but if you have an example project where this separation isn’t maintained please point us towards it.
  - Hristo Hristov April 30, 2019 7:07 am 0
    
    “I believe the recommendation from CMake is to keep the source tree separate from the binary tree – but I think in most cases the new defaults will do this but if you have an example project where this separation isn’t maintained please point us towards it.”
    ${projectDir}\\out\\build\\${name} -> puts the \\out\\build\\${name} in the same directory where the root CMakeLists.txt file is located. IHMO this is a violation of CMake’s recommendation to keep the source tree separate from the binary tree. CMakeLists.txt is also a sort of a “source” file. \out\\build\\${name} should be out of ${projectDir} as it used to be before this update. This means when you open the folder containting CMakeLists.txt VS is going to index all the build artifacts located in \\out\\build\\${name}. When I started using VS for its CMake support I came across a problem – VS failed at indexing a source folder which contained like 30 GB of artifacts and assets. The C++ sources were probably less than 1Mb and all this happened because originally VS would put the build directory inside of the source directory by default and the authors of the projects never cared to separate them (and it wasn’t that easy anyway).
Moritz Beutel June 3, 2019 2:06 pm 0

Intellisense support for CMake files is appreciated, but I sorely miss the configurability available for other languages. (There is no “CMake” node under “Options…” | “Text Editor”.)

In particular, I’d like to disable “Auto list members”, which constantly gets in the way. Repro: Open any CMake script file, navigate to an empty line, hit Tab twice. The first Tab key opens the function list, the second Tab key inserts the element first position (`add_compile_definitions`). All I wanted was two tabs!!