[feature] [toolchain.cmake] Set platform and toolset only if generator matches Visual Studio

[Minimonium]

Use case: Using MSVC with Ninja as CMake Generator. It doesn't support PLATFORM and TOOLSET variables and errors out on them.

Consider generating the template like this:

if(CMAKE_GENERATOR MATCHES "Visual Studio")
        {% if generator_platform %}
        set(CMAKE_GENERATOR_PLATFORM "{{ generator_platform }}" CACHE STRING "" FORCE)
        {% endif %}
        {% if toolset %}
        set(CMAKE_GENERATOR_TOOLSET "{{ toolset }}" CACHE STRING "" FORCE)
        {% endif%}
endif()

[Minimonium]

Related to #5737

[memsharded]

It seems that this will not be resolved until build-time, when cmake is actually called.
Maybe it makes sense to model that in the toolchain already, that is, that the toolchain is aware that it will be using Ninja instead of MSBuild. It is likely that there will be other things to fix as well, and it might be very useful to not have to wait until build time and things are more explicit and simpler. Just an idea to consider, lets have a look for next Conan 1.29 if possible.

[Minimonium]

The issue is that we should consider how to integrate toolchains with IDEs first and foremost, it's crucial if we want gain popularity with a wider user base.
For example, my case is VSCode and CMake Tools which sets the environment for you, so you don't expect it to hijack the generator since it's configurated via their specific mechanisms. A potential Conan extension in there should absolutely be compatible with it to not reinvent the wheel.
We need to collect experience from users of other CMake compatible IDEs such as CLion, Visual Studio, QtCreator, and such to work from there first.

[memsharded]

The issue is that we should consider how to integrate toolchains with IDEs first and foremost, it's crucial if we want gain popularity with a wider user base.

Possibly the biggest goal of toolchain() is to provide a better integration with build systems and IDEs. Being the core concept of toolchains that they generate files that can be used by the build systems, instead of calling the build systems and passing a lot of stuff via command line and environment, I would say that toolchains should definitely help in a better integration with the IDEs too. The plan for next release is to do some more steps and provide preliminary support for MSBuild, Autotools and Meson toolchains, and hopefully more feedback starts to come.

[memsharded]

I am having a look and trying to add testing that includes the Ninja build system: https://github.com/memsharded/conan/tree/feature/toolchain_cmake_ninja

There are important design issues here, which require new solutions. Nothing that can be done right now, will keep working in next 1.31.

[Nipheris]

Hi @memsharded !

It seems that this will not be resolved until build-time, when cmake is actually called.

What do you mean when say "will not be resolved"? The if block that @Minimonium propose to use is processed by CMake itself at the cmake-generation step (when files for the underlying build system like MSBuild/Ninja/etc are generated), and CMAKE_GENERATOR is already defined at this moment. We've met the same problem now, and after patching the generated cmake_toolchain.cmake (wrapping the set(CMAKE_GENERATOR_PLATFORM.. in the if statement) Ninja build files are generated without any issues.

Why not merge this solution in the next release? :)

Edit: to be precise, I think we should implement the same logic like in is_generator_platform_supported, but using generated CMake code. Green Hills MULTI should also be considered.

[memsharded]

It seems that #8333 is not really necesary. This was fix earlier, and the toolchain is checking that the generator is "Visual" one, otherwise it will not add platform and toolset variables.

[memsharded]

It was possibly fixed in #8192, that is also part of 1.33.