[package] any: CMake Header-only package with a compiler setting fail to build on Windows

[Minimonium]

CMake build helper on Windows uses settings to determine which CMake generator to use.
In older Conan versions the behavior was a failure in configure step, but since that, it seems to be fixed for the default case, so I failed to properly double-check that. My apologizes.

If there are no settings in a recipe - Conan delegates the generator detection to CMake.
It may be a problem in some cases but I've failed to reproduce it (/cc @theodelrieu ):

When expliciting CC=cl.exe in a profile, and creating a package which declares no settings (nlohmann_json/3.8.0) Conan will not run the MSVC command tools prior to running CMake, thus the CMakeDetermineCCompiler.cmake script will fail

If a package requires a compile setting for some unrelated work as a C++ standard support detection - it fails to configure the project because of faulty logic in here:
https://github.com/conan-io/conan/blob/develop/conans/client/build/cmake.py#L158

Affected recipes:
#1946
#1945
#1939
#1936

/cc @Croydon @SSE4

Profile

[settings]
os=Windows
os_build=Windows
arch=x86
arch_build=x86
compiler=Visual Studio
compiler.version=16
compiler.toolset=v141
compiler.runtime=MDd
build_type=Debug
compiler.cppstd=17
[options]
[build_requires]
[env]

Example to reproduce

$ conan create ./recipes/kitten/all kitten/0.1.0@user/testing

Result

ERROR: kitten/0.1.0@user/testing: Error in build() method, line 48
        cmake = self._configure_cmake()
while calling '_configure_cmake', line 34
        cmake.configure(source_folder=self._source_subfolder,
        ConanException: CMake does not support toolsets with generator "None:.Please check your conan profile to either remove the toolset, or change the CMake generator.

Note: It could happen that not all settings are required or not all

[danimtb]

@Minimonium I guess the other settings like build_type are also needed, right?
I think having the settings there as input is fine and controlling the information that goes into the package_id afterward is clear as well

[Minimonium]

@danimtb Well, CMake detects a default compiler and picks up an unrelated to profile configuration, for example in my case it's a Release x64 despite me having a Debug x86.

In normal use of CMake, even for header-only libraries, it'd be a problem (unless using a void hack) because CMake produces fixed to a configuration config files, which would fail to be detected. But CCI removes them.

The only issue may arise if a header-only project does some conditional file generation depending on the configuration.

[SSE4]

is this a big deal? I believe you always can set CONAN_CMAKE_GENERATOR to the one you need, and it will always use the right generator. changing each recipe might be too extensive.

@danimtb @jgsogo do you think we should merge all these PRs? for me it sounds like we have a bug around https://github.com/conan-io/conan/blob/c923c692fb14dd3ad0a66bab308b4a59f6a037dc/conans/client/build/cmake.py#L159

[jgsogo]

I think all the packages affected are already merged, right?

Will this problem raise if we run conan test <ref> /path/to/test_folder for every configuration (for header-only packages)?

[Minimonium]

Yep! Thank you a lot.
About the conan test - it'd not help this issue since it'd reuse an existing header-only package, which is not a problem at all. The problem is that if you want to --build all - you'll not be able to with such a recipe. I think we need to either look into the Conan codebase solution for that, to clean up the toolchain detection logic - or into looking for a hook for CCI.

@SSE4 We do have a bug in the toolchain detection, but I'm not sure how to properly handle it to not make a timebomb for a recipe that would need some other information later on or another change in the codebase that would render any workaround useless. I also don't think that having a condition to have an env variable for a recipe to properly work on a fairly popular platform like Windows MSVC is a good solution.

[jgsogo]

I think this issue would've been fixed (because CCI would've failed) if this PR were in place: conan-io/conan#7327

[Minimonium]

@jgsogo Indeed!

Also, I think that this issue may be closed now since all the recipes affected were merged. If anyone wants to proceed with the discussion - feel free to open the issue.