CMake 3.14 and Performance Improvements
In Visual Studio 2019 version 16.1 we have updated the version of CMake we ship inbox to CMake 3.14. This comes with performance improvements for extracting generated build system information. Additionally, we now support virtually all the Visual Studio capabilities regardless of the CMake binary origin so long as the CMake version is at least 3.14. The main reason for this is the introduction of the file-based API, which we now support, and which provides a new way for retrieving semantic information. This is now the recommended way to connect an IDE to CMake, the old CMake server being deprecated, and we are an early adopter of the feature.
Visual Studio Performance Improvements
The indexing is now significantly faster for code opened via Open folder, and as a result IntelliSense is available considerably faster than in Visual Studio 2017. As an example, in the LLVM codebase, IntelliSense becomes available at least 2 times faster in Visual Studio 2019. Additionally, a new indexing algorithm lights up IntelliSense incrementally while the folder is being indexed.
In Visual Studio 2017 on average it takes 3 min from the point of opening the LLVM folder, to the point where you have IntelliSense, including generation. In Visual Studio 2019 it takes 1:26 min, including generation.
CMake 3.14
We now ship CMake 3.14 in-box with Visual Studio. This contains the new file-based API, and support for the Visual Studio 2019 generators. To see the full set of changes, please see the CMake 3.14 release notes.
Visual Studio 2019 Generators
CMake 3.14 introduces support for the Visual Studio 2019 generators. The new generator is called “Visual Studio 16 2019”, and the platform targeting is simplified. To use a specific platform, use the -A argument. For example, to use the Visual Studio 2019 generator targeting the x64 platform: cmake.exe -G “Visual Studio 16 2019” -A x64
File-based API
The file-based API allows a client to write query files prior to build system generation. During build system generation CMake will read those query files and write object model response files. Prior to this API’s introduction we were using the cmake-server to get the equivalent information. We‘re still supporting the old model, but starting with 3.14 we can now support the new model as well. One of the differences in our CMake fork on github was the backtrace information needed for our Targets View feature inside Visual Studio. Prior to CMake 3.14 we needed the CMake version from our fork, in order for Targets View to work properly. Now, with the file-based API this is no longer required.
The file-based API provides a simpler, standard path to the future, with official support in CMake itself. We expect most users to see either performance improvements or not notice any degradation of performance. Extracting the information to populate the Visual Studio UI is faster because we are just reading the response files rather than running CMake in long-running server mode, there is less memory usage and less overhead associated with creating and maintaining processes.
These value-added features light up automatically when you update to Visual Studio 2019 version 16.1 Preview 2.
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 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.
Light
Dark
7 comments
Nice, but we need proper MSBuild support for clang-cl.
thank you for the feedback, we are working on it, please stay tuned 🙂
Nice! Being able to use a separate CMake instead of the one bundled with VS solves a lot of headaches for us! I look forward to trying this out 🙂
I’m big fans of CMake support in Visual studio and have a long time use on it. With vcpkg, it seperates me from downloading libraries or configurating them to different triplet VC++ configurations(x64,x86,x64 Debug,x86 Debug, etc..). But there is still a little bit problem on it, such as following. ## Debug. Debugging on CMake project is supported and behaviours like traditional VC++ projects. Debugging itself is well-formed, but the `launch.vs.json` is buggy: – Sometimes, the custom added configuration is mark as invalid suddenly(usally it happens when I pull codes from git and build, before then, it’s fine and I never modify them) and can not be selected in launch menu FOREVER. – Even if I delete the auto-generated configuration, it’s not removed and still display in launch menu. – When I switch file to another, I really don’t hope the launch menu to be switched automaticlly. ## Test. The `Test Explorer` can not detect CMake tests, but the generated CMake cache, as VC++ solution(Visual Studio 2019 generator), can detect. ## IntelliSense – Sometimes when I open the CMake folder and pull from git(using Visual Studio Team Explorer), the IntelliSense will stop its work until I reopen the folder. – If I create a new file in CMake, The IntelliSense for that new file is not worked until I execute menu [Project]-[Generate cache for project] and then reopen the folder.
Sometimes, the custom added configuration is mark as invalid suddenly(usally it happens when I pull codes from git and build, before then, it’s fine and I never modify them) and can not be selected in launch menu FOREVER
It’s because I switched the generateor from Ninja to Visual Studio 2019, the `projectTarget` needs to be changed and modified.(For example, Ninja expects `<path-to-project>\<executable-name>` and Visual Studio 2019 expects `<path-to-project>\Debug\<executable-name>`)
But I still recommand that a hint is given to indicate why the configuration is invalid When user can not select his configuration in menu.
Thank you for using CMake in Visual Studio and for reporting these issues. If you haven’t done so already, the next time that you run into these problems, could you Report a Problem? Here are the instructions for how to do that:
https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2019
If you are able to provide small repro projects that would help in the investigation. Or you can send email to cmake@microsoft.com and we can work with you to investigate.
I’m very happy about marriage of Microsoft Visual Studio with CMake ( and also with Ninja ).
I thank You for this technical insight.
I wonder why Microsoft Visual Studio carries over recent revion of CMake but it does not carry over cmake-gui, that is solely for Microsoft o.s. boxes. So stanting things, I still have to remember to point to KITWARE for a new revision of CMake just for having cmake-gui on my Windows box.