[question] Conan V2: Compiler msvc requires try...except when deleting libcxx

[uilianries]

When packaging a C project with Conan, the regular way to discard C++ from the package ID is by removing some settings from the compiler:

def configure(self):
    del self.settings.compiler.libcxx
    del self.settings.compiler.cppstd

However, with the introduction of msvc as compiler on Windows and Conan V2 behavior, all recipes need to be updated, otherwise, it will fail:

from conan import ConanFile

class TestConan(ConanFile):
    settings = "arch", "build_type", "compiler", "os"

    def configure(self):
        del self.settings.compiler.libcxx
        del self.settings.compiler.cppstd

λ conan --version
Conan version 2.0.0-beta2
λ conan create . --name foo --version 0.1
...
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows
...
ERROR: foo/0.1: Error in configure() method, line 10
        del self.settings.compiler.libcxx
        ConanException: 'settings.compiler.libcxx' doesn't exist for 'msvc'
'settings.compiler' possible configurations are ['cppstd', 'runtime', 'runtime_type', 'toolset', 'update', 'version']

However, on Conan 1.x, we do not have same behavior when using msvc as compiler, also, it does not use libcxx neither cppstd: https://docs.conan.io/en/latest/reference/config_files/settings.yml.html

It would be great if we could have the same behavior for Conan 2.0, otherwise, we will need to update all recipes on CCI.

Environment Details (include every applicable attribute)

• Operating System+version: Windows
• Compiler+version: msvc
• Conan version: 2.0.0-beta2
• Python version: 3.10

/cc @jgsogo

[lasote]

The settings deletion should be protected with try/catch as noted in the migration guide. We try to avoid "no-op" operations that can cause silent bugs.

Said that we have pending to introduce a language recipe attribute or similar to make Conan smarter and manage that deletion automatically, as in other situations like the fpic option. This implementation might have more implications like wider compatibility and so on, but we haven't planned yet when to do it. Right now, protecting the deletion is required.

[danimtb]

yes. this is covered in the migration guide and it also happens with options. I think we can close this question as answered