Conan profile new default --detect does not detect/configure Visual Studio 2022 correctly resulting in failing builds

[robindegen]

Environment Details (include every applicable attribute)

• Operating System+version: Windows 10 2H20 (Docker image)
• Compiler+version: Visual Studio 2022 Build Tools (19.30.30706)
• Conan version: 1.43.0 (installed system-wide through pip)
• Python version: 9.3.6
• Cmake version 3.22.1

Steps to reproduce (Include if Applicable)

Create the default profile on a system with only Visual Studio 2022 installed:

conan profile new default --detect

Content:

[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=msvc
compiler.version=193
build_type=Release
[options]
[build_requires]
[env]

I think the problem lies with the detected default profile. It set the compiler to "msvc" instead of "Visual Studio". And the compiler.version is set to 193; instead of "17" which is what I would expect.

If I then build the package with this strange profile; conan will try to build with mingw; which fails on multiple levels. Mingw is not even installed on this sytem. It first complains there is no settings.compiler.cppstd or settings.compiler.runtime set. If I do set this manually; then it will still try to build through mingw:

git clone https://git.aeons.dev/aeon-engine/aeon-conan-packages.git
cd aeon-conan-packages
conan create .\recipes\zlib\all\ zlib/1.2.11@aeon/testing -s build_type=Debug

PS C:\aeon-conan-packages> conan create .\recipes\zlib\all\ zlib/1.2.11@aeon/testing -s build_type=Debug
Exporting package recipe
zlib/1.2.11@aeon/testing exports: File 'conandata.yml' found. Exporting it...
zlib/1.2.11@aeon/testing exports: Copied 1 '.yml' file: conandata.yml
zlib/1.2.11@aeon/testing exports_sources: Copied 1 '.txt' file: CMakeLists.txt
zlib/1.2.11@aeon/testing exports_sources: Copied 2 '.patch' files: 0002-gzguts-xcode12-compile-fix.patch, 0003-cmake-fix-msys2-subsystem.patch
zlib/1.2.11@aeon/testing: The stored package has not changed
zlib/1.2.11@aeon/testing: Exported revision: b9a354d7b156c8c346fcc098bf840396
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=msvc
compiler.cppstd=20
compiler.runtime=dynamic
compiler.runtime_type=Debug
compiler.version=193
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

zlib/1.2.11@aeon/testing: Forced build from source
zlib/1.2.11@aeon/testing (test package): Installing package
Requirements
    zlib/1.2.11@aeon/testing from local cache - Cache
Packages
    zlib/1.2.11@aeon/testing:d04cd4d5e7a2725ea73c214c3152343f985fc89b - Build

Installing (downloading, building) binaries...
zlib/1.2.11@aeon/testing: WARN: Build folder is dirty, removing it: C:\Users\ContainerAdministrator\.conan\data\zlib\1.2.11\aeon\testing\build\d04cd4d5e7a2725ea73c214c3152343f985fc89b
zlib/1.2.11@aeon/testing: Copying sources to build folder
zlib/1.2.11@aeon/testing: Building your package in C:\Users\ContainerAdministrator\.conan\data\zlib\1.2.11\aeon\testing\build\d04cd4d5e7a2725ea73c214c3152343f985fc89b
zlib/1.2.11@aeon/testing: Generator cmake created conanbuildinfo.cmake
zlib/1.2.11@aeon/testing: Aggregating env generators
zlib/1.2.11@aeon/testing: Calling build()
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
zlib/1.2.11@aeon/testing:
zlib/1.2.11@aeon/testing: ERROR: Package 'd04cd4d5e7a2725ea73c214c3152343f985fc89b' build failed
zlib/1.2.11@aeon/testing: WARN: Build folder C:\Users\ContainerAdministrator\.conan\data\zlib\1.2.11\aeon\testing\build\d04cd4d5e7a2725ea73c214c3152343f985fc89b
ERROR: zlib/1.2.11@aeon/testing: Error in build() method, line 68
        cmake.configure(build_folder=self._build_subfolder)
        ConanException: Error 1 while executing cd C:\Users\ContainerAdministrator\.conan\data\zlib\1.2.11\aeon\testing\build\d04cd4d5e7a2725ea73c214c3152343f985fc89b\build_subfolder && cmake -G "MinGW Makefiles" -DCONA
N_LINK_RUNTIME="/dynamic" -DCMAKE_BUILD_TYPE="Debug" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="msvc" -DCONAN_COMPILER_VERSION="193" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="C:\Users\ContainerAdministrator\.
conan\data\zlib\1.2.11\aeon\testing\package\d04cd4d5e7a2725ea73c214c3152343f985fc89b" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INST
ALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -Wno-dev C:\Users\ContainerAdministrator\.conan\data\zlib
\1.2.11\aeon\testing\build\d04cd4d5e7a2725ea73c214c3152343f985fc89b

I think the profile detection is broken with Visual Studio 2022.

If i change the profile manually to this; everything works as expected:

[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=Visual Studio
compiler.version=17
build_type=Release
[options]
[build_requires]
[env]

[robindegen]

Update: Changed the title and description after finding the root cause

[memsharded]

Hi @robindegen

This is not a bug, the new msvc is the new setting definition for the Visual Studio compiler, the one that will supersede the Visual Studio one in Conan 2.0 ("Visual Studio" will be removed in 2.0).

As it is necessary to keep improving the msvc we have provided this detection already for VS 2022. It is true that the legacy integrations (like cmake_find_package, cmake) will probably have a worse support for msvc and the new ones (CMakeDeps, CMakeToolchain) will support better msvc. They are experimental, but those are also the ones that will replace the former ones in Conan 2.0

I would also like to highlight that for production the profile auto-detection should not be trusted. Using your own profiles (probably managed with conan config install) is the recommended approach. To better emphasize this behavior, Conan 2.0 is also removing the automatic detection and creation of a default profile when it doesn't exist, and it will require a explicit command in 2.0 to detect and create a profile, that will include warnings that such profile output will not be considered stable, and subject to change its defaults from release to release)

[robindegen]

But if I use it as-is, all the builds fail. Even packages on the conan hub are broken with this change; since it tries to build with mingw if you do that. Shouldn't such a change be at least backwards compatible in a sense that it doesn't just break installations on new systems? I have to manually tweak profiles now to get it to build on all docker images; where before the auto detection worked fine.

Even if i don't create any profile and just let it build the first time; the autodetection kicks in and also fails the same way. The reason why is also not very clear; which is likely going to cost a lot of people a lot of time

I would expect if this change is indeed the way forward; then conan hub packages still work? That would mean that the cmake generator also has to work; since that is what a lot of those recipes use

[memsharded]

But if I use it as-is, all the builds fail. Even packages on the conan hub are broken with this change; since it tries to build with mingw if you do that. Shouldn't such a change be at least backwards compatible in a sense that it doesn't just break installations on new systems? I have to manually tweak profiles now to get it to build on all docker images; where before the auto detection worked fine.

Yes, but there is already a bunch of users moving to the new integrations and trying to use msvc setting in their recipes. Recall that ConanCenter usage represents around 20% of Conan usage, as there is way more usage inside companies with their own recipes than in ConanCenter. If the default profile doesn't start to default to msvc, then it will be a problem for them too. We are in the middle of the migration to the new approaches to be ready for 2.0 (recall that we are already in alpha.2 release, so it is getting closer and closer), and that means that at some point, for the new features, and things like new compilers like VS 2022, we need to do the switch.

I will discuss with the team, to see if it makes sense to extend the "Visual Studio" default, for 1 or 2 releases more, but please take into account the above comment, that the automatically detected profile is not recommended for production, and the automatic creation of such profile will even be removed in 2.0, so better start planning to manage your own profiles.

[robindegen]

@memsharded I agree with the idea and i understand completely; but then it should be a bit more clear that this is the case for the end-user. Maybe the detect should already state this in a warning. Currently there is no indicidation what-so-ever; and it just seems to randomly break when i update to me as an end-user who is not up to date with all these internals. I didn't even know that 2.0 was in alpha

[memsharded]

We will have a look at next release to see if the legacy integrations can be easily fixed without breaking risks.

In any case, for reference for other readers too, changing the default automatically generated profile can be done with conan profile settings.compiler="Visual Studio" default (and similar for the version).

[franramirez688]

Thanks, @robindegen for reporting the issue. Indeed, it is a bug.

It's already solved here: #10195 (pending of being reviewed/merged)
It'll be released in the next Conan 1.43.2 patch version asap.

[czoido]

Closed by: #10195 to be released soon in Conan 1.43.2