[question] CMakePresets and Visual Studio 2019 / 2022 compatibility observations

Question 1

Should the Conan CMakePresets generator target a user configurable schema version? And/or target a minimum schema version of 2?

VS2019 ships with a build based on CMake 3.20 / version 2, and VS2022 ships one based on CMake 3.22 / version 3.

The choice of targeting schema version 4 means VS2019 / VS2022 are necessarily excluded from consuming some or all of these generated files.

Context

The Conan 2.0 doc rightly calls out needing CMake 3.23 or greater when using CMakePresets:

CMake >= 3.23 is required because the “include” from CMakeUserPresets.json to CMakePresets.json is only supported since that version.

_See https://docs.conan.io/en/2.0/examples/tools/cmake/cmake_toolchain/build_project_cmake_presets.html?highlight=cmakepresets#building-the-project-using-cmakepresets_

According to the cmake-presets doc:

The supported schema versions breakdowns as follows:

Schema Version	CMake Version	Notes
1	3.19
2	3.20	VS2019
3	3.21-3.22	VS2022 Schema introduced toolchainFile
4	3.23	Schema introduced include
5	3.24

But, it’s not like the generated CMakePresets files are terribly complicated.

For VS2019, we could certainly generate a CMakeUserPresets.json file in the source folder that looks like the CMakePresets.json generated in the build folder, but instead of using toolchain, defines CMAKE_TOOLCHAIN_FILE as a cacheVariable.

This would allow the generated preset to be recognized by more IDEs.

Question 2

Should the Conan CMake presets generator support setting up a cross compile development environment?

The conanbuild.bat/conanvcvars.bat appears to capture this information for command line usage, but the generated CMakePreset files are lacking it, which means opening through the IDE is liable to give us a different environment than what Conan’s CMake build helpers would have chosen.

Context

I’m currently building with the Visual Studio compiler using the Ninja generator.

In Conan 1.x, we’ve long leveraged cross-compiling via setting arch_build=x86_64 and arch=x86, which lets me use the x64 compiler tools and still target an x86 binaries. And I’m exploring what it takes to get this working with an eye towards Conan 2.0, build/host profiles, CMakeDeps, CMakeToolChain, and CMakePresets.

I’m not sure how much (or all) of this is VS specific, but VS allows you to configure which dev prompt the IDE chooses by leveraging a pre-defined environment (e.g. msvc_x86_x64)

"configurePresets": [
	{
		"name": "Debug",
		"inheritEnvironments": [ "msvc_x86_x64" ],
		"generator": "Ninja",
...
	}
]

or setting up your toolset/toolchain more manually:

"configurePresets": [
	{
		"name": "Debug",
		"architecture": {
			"value": "x86",
			"strategy": "external"
		},
		"toolset": {
			"value": "host=x64",
			"strategy": "external"
		},
		"generator": "Ninja",
...
	}
]

Conan has to know the cross compile information in order to get its dependencies right, so depending on what schema version you’re targeting, these snippets could be an optionally included generated CMakePresets file in the build folder, or just included directly in the generated CMakeUserPresets.json, which would allow VS to pickup the right environment for use.

Admittedly, the cross-compile scenario is likely somewhat bespoke. For our usage, it’s not strictly required anymore, but there was a time where we needed to leverage the x64 compiler in order to avoid running out of RAM when processing a template heavy Boost Spirit grammar. This is aggravated somewhat by the VS CMakePresets support error handling / reporting being near non-existent. So often CMakePreset failures result in the wrong environment being loaded (x64 by default), and then the build failing when it notices the environments aren’t correct.

---

• I’ve read the CONTRIBUTING guide.

---

As always, thanks for your continued efforts developing, supporting, and maintaining this project and its community.

[lasote]

I’ve created a couple of issues to try to ease the usage of the CMakeUsersPresets.json, at least we want to try and see how the implementation looks like. I will use this issue to add the architecture/toolset to the configurePreset when using the Ninja generator.

[thorntonryan]

Thanks for the ideas! I hadn’t considered those yet.

Looking at the documentation, CMAKE_GENERATOR_PLATFORM is only supported on certain generators:

Platform specification is supported only on specific generators:

• For Visual Studio Generators with VS 2005 and above this specifies the target architecture.
• For Green Hills MULTI this specifies the target architecture.

It also only seems to affect the target architecture. Whereas I’m hoping to adjust the host toolset too, in order to pick up the x64 versions, which can then target x86 applications.

We’re using the Ninja generator, so while that might work for some applications, I don’t think CMAKE_GENERATOR_PLATFORM would help us here. We’ve certainly enjoyed using MSVC compilers with Ninja to increase build parallelization, maybe we’re just a minority?

And the CMakePresets doc almost make it sound like that wouldn’t work anyway:

generator An optional string representing the generator to use for the preset. If generator is not specified, it must be inherited from the inherits preset (unless this preset is hidden). In version 3 or above, this field may be omitted to fall back to regular generator discovery procedure.

Note that for Visual Studio generators, unlike in the command line -G argument, you cannot include the platform name in the generator name. Use the architecture field instead.

The CMakePresets doc seems to suggest we should be using the architecture field instead (like I’ve outlined above).