I am curious, what are some of the intended use cases for CMakePresets.json that’s new for CMake 3.19. Is for Visual Studio / IDE users to avoid a lot of set() statements in CMakeLists.txt? Say one has 2 or 3 common use cases and CMakePresets.json avoids a lot of set() and/or a lot of cmake -D options?
2 Likes
The presets files allow you to define a commonly used set of cache options and other things that would normally only be settable on the cmake command line the first time it is run for a build. It can encapsulate selection of the generator, build directory location, various debugging options, etc.
While the Visual Studio IDE is the obvious place where these presets files will be useful, they could also be helpful for conveniently defining CI build options or just setups that developers frequently use between projects. I have just opened a few preset-related issues in gitlab for problems exposed with 3.19.0-rc1 for some of these use cases. You might choose to set up things for a variety of different generators for example (e.g. with Xcode you might use it to set some code signing options).
BTW the presets can also be selected in cmake-gui (once some bugs are fixed). That is another way that presets simplify the life of developers working with a project for the first time.
Lastly, there are two presets files. One is meant for the project to define (CMakePresets.json), the other is for user-provided presets (CMakeUserPresets.json). These represent the two main categories of use cases and target different scenarios.
1 Like
Thank you. I have started using CMakePresets.json for projects that need to run on HPC and user laptops. The cmake --preset= allows me to give a range of defaults, for example telling CMakeList to build external libraries via FetchContent instead of find_package via cache variables set in CMakePresets, which of course users can locally override with their UserPresets.
Also for HPC I’ve used I can add presets, and users can make their own too.
Quite useful even if that wasn’t CmakePresets prime use case.
I find it most useful for getting settings out of CMakeLists.txt.
My general philosophy is that nothing should go into the CMakeLists.txt that isn’t absolutely required to build the library (my rules for applications are more lax). For instance, I’m in the process of moving warning flags to presets like gcc-linux-debug, clang-macos-release, etc. in my own projects.
It’s the same deal with BUILD_SHARED_LIBS and CMAKE_BUILD_TYPE (for single-config generators). With presets, I can’t forget to set those anymore and I can remove the code that warns me if they’re not set.
I can also easily store packaging configurations. For Ubuntu DEBs, CMAKE_INSTALL_LIBDIR should be set to lib/x86_64-linux-gnu, but it should be left alone for macOS tarballs. Now these are presets, rather than option()s or other cache variables that control sets of CPack variables.
All of this being factored out of the CMakeLists.txt files means that I don’t have to inflict this complexity on my FetchContent users, the vcpkg maintainers, people just trying to get started with my library, etc.
1 Like
Does anybody know if the Visual Studio Team has plans to replace their own CMakeSettins.json file with the CMakePresets.json file from CMake. I think they were created for the same purpose.
Currently Visual Studio will create its own file when you open a CMakeCache.txt file in CMake mode. Using the official config file would be much nicer.