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

[thorntonryan]

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]

Hi! Thanks for your support.

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.

Yes, we could, but the CMakeUserPresets.json has two purposes:

1. Be in the same folder as the CMakeLists.txt so the IDEs find it. (we would be ok with this)
2. Aggregate all the different CMakePresets.json that come from conan install, so presets from different configurations (build type, architectures... etc). (we would lack this)

About cross-building, it should be covered nicely by the CMakeToolchain and the cmake_layout. Check this to know more.

I don't think we should introduce a config to lower the schema of the CMakePresets because we would be missing important capabilities and would make it harder to maintain. I would suggest upgrading the CMake version of VS2019, I didn't try it but is apparently possible.

[thorntonryan]

About cross-building, it should be covered nicely by the CMakeToolchain and the cmake_layout. Check this to know more.

Thanks for fielding my questions!

I guess that's where I'm struggling. I'm seeing a bit of a gap between CMakePresets and and CMakeToolchain regarding which environment is chosen.

The cmake_layout capability seems more about ensuring the correct paths are used for each configuration (e.g. Debug or Release). At the moment, I'm focusing on a single configuration generator, but I can see how this will be great in order to produce a CMakePresets file for both Debug/Release builds.

However, the generated CMakeToolchain doesn't define which compiler you're using. It just says you're using cl. And importantly it doesn't say what environment that cl comes from.

For example, the CMakeToolchain doesn't know whether cl should be coming from the x64_x86 cross tools:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x86\cl.exe
or just the native x86 tools:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x64\cl.exe

To the best of my knowledge, cross-compiling environment information seems captured via conanbuild.bat -> conanvcvars.bat ... and comes from the new CMake build helper, which prepends a call to conanbuild.bat && prior to doing anything, which ensures the right env is in play when Conan calls these things from the command line.

However, since these details aren't captured in the CMakePresets file, it seems like there's opportunity to accidentally obtain a different environment in your IDE than what Conan would have used.

[thorntonryan]

I don't think we should introduce a config to lower the schema of the CMakePresets because we would be missing important capabilities and would make it harder to maintain. I would suggest upgrading the CMake version of VS2019, I didn't try it but is apparently possible.

I totally sympathize. That would be a great approach if it worked reliably. Unfortunately, upgrading the CMake version that way doesn't always appear to work in practice.

I have CMake 3.23 on my system, so I should be able to handle schema 4. And I can configure my presets using the command line. But the same CMakeUserPresets.json file won't configure in the IDE. VS2019 seemingly can't handle the include and goes off the rails, pulling in a completely different environment (x64 not amd64_x86).

I had tried that before, but failed to mention in OP. But I sanity checked my work just to be safe and can confirm it does not work reliably. The include statements give VS2019 grief, regardless of which cmakeExecutable you use. VS2019 does seem to allow the toolchain keyword, letting you target schema version 3 though, nevermind...it just fails with obscure parsing warnings

Let me see if I can confirm that VS2022 has the same problem, but I would expect it to fail the include for the same reasons.

That's a harder problem, because I haven't yet figured out how to down target an old compiler in a new IDE, but I think it should be possible using "toolset": { "strategy": "external", "value": "v142,host=x64" }

[thorntonryan]

The error handling is at least better in VS2022:

Severity Code Description Project File Line Suppression State
Error (active) Visual Studio supports CMakePresets.json files versions 2 to 3. Please update your CMakePresets.json file. More info: aka.ms/cmakepresetsversion C:\projects<app>\CMakeUserPresets.json 1

Frustratingly, this error message is even at odds with the linked documentation, which states version 2 or later.

Which I think highlights that the decision to target schema version 4 as the minimum, necessarily excludes IDE usage in both VS2019 and VS2022 because the IDE itself does some amount of parsing.

If that's the intent, then maybe we should adjust the documentation to highlight this IDE limitation?

[lasote]

To the best of my knowledge, cross-compiling environment information seems captured via conanbuild.bat -> conanvcvars.bat

Let me take a look at this and check if we can do something.

[lasote]

Hello! I've been checking and should be only needed to use the CMakeToolchain to cross-build, a line is introduced in the toolchain with the CMAKE_GENERATOR_PLATFORM that completes the definition of the generator in the configurePresets.

[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).

[lasote]

Thanks for your answer, makes sense. I'll take a look at the architecture/toolset fields and do some tests.

[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.

[manuelnp]

I think the issue here is that Conan is setting the architecture too late. Instead of defining it in the preset file:

    "configurePresets": [
        {
            "name": "default",
            "displayName": "'default' config",
            "description": "'default' configure using 'Visual Studio 16 2019' generator",
            "generator": "Visual Studio 16 2019",
->          "architecture": "x64"
            ...

Conan is setting the value inside conan_toolchain.cmake file:

set(CMAKE_GENERATOR_PLATFORM "x64" CACHE STRING "" FORCE)

But CMake checks the cached value as early as possible, after reading the preset but before parsing the toolchain file.

[memsharded]

Conan is setting the value inside conan_toolchain.cmake file:

yes, the thing is that Conan must work (CMake 3.15 support) with toolchains as the main mechanism. It is not possible to rely on presets only. So the architecture definition must be in the toolchain file, for that majority of users still not using presets, and it is not possible to know if users will be using presets or not, as that happens completely outside Conan.

[manuelnp]

Could Conan set both preset and toolchain?

[memsharded]

I am having a look at this, and apparently it is possible in my preliminary tests, but I recall having some problems in the past.

In any case, I am also not able to reproduce the potential issues you are citing, everything seems to be working fine. Could you please detail the scenario in which this would be failing? I have tried both Visual Studio and Ninja generators, and both seem to do the right things regarding the architecture with it defined in the toolchain. If you have some code, CMakeLists.txt, etc to reproduce the issue, that would be good

[manuelnp]

Hi @memsharded, find attached a simple project to reproduce the issue. I'm using the following configuration:

CMake 3.25.2
Conan 1.59.0
Conan profile default

[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows

Steps to reproduce (please notice you need to call twice cmake --preset default):

1. Unzip the project and place the profile inside conan profiles folder
2. conan install .
3. cmake --preset default

(output OK)

4. cmake --preset default

CMake Error: Error: generator platform:
Does not match the platform used previously: x64
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.

sandbox.zip

[memsharded]

I think this specific issue is covered in #13792, so closing again, please lets follow up there.