[question] Should CCI recipes begin to support the "new" msvc compiler in settings?

[SpaceIm]

Some consumers might want to use msvc instead of Visual Studio in their profiles, and I guess many CCI recipes break (missing system libs, wrong check of runtime).
Maybe we should start to:

• replace things like self.settings.compiler == "Visual Studio" by self.settings.compiler in ["Visual Studio", "msvc"]
• properly check compiler.version if it's msvc (not the same versionning than Visual Studio)
• take into account that if msvc, settings.runtime is split in settings.runtime and settings.runtime_type

[prince-chrismc]

Yes ❤️ I'd love this feature!

[jgsogo]

Hi! You all know that my thought is that if something is not tested in the CI, it might eventually become broken. On the other hand, we all really appreciate the efforts to support more configurations in recipes (thanks for all those iOS -related fixes) and we will really like to push new configurations... but we need to keep the budget under control.

On our plans, we would like first to remove some configurations for technical reasons (read latest comments here: #4761 (comment)) and probably some others if they are not being requested (@danimtb will have numbers soon). Although we've always thought about iOS, Android,... it is very true that msvc compiler should be also a high priority (ping @SSE4 ).

---

[prince-chrismc]

Would it be easier to close/link these issues and have a GitHub discussion thread(s) about this topic? I am not sure it appears to the dame audience but it might be useful

[SSE4]

until we have usage stats for the most requesting packages, there are no plans to add new compilers, architectures, operation systems, etc.
the short term plan is to remove configurations new docker images can't handle - see also #4761 (comment)
after that, with stats, we can decide what to add first, it could be new compiler version (e.g. Visual Studio or GCC or Clang), or new platform (e.g. iOS or Android or Emscripten), or new architecture. that might be even something that even not on our radar (FreeBSD, Solaris, etc.).
I think we will be able to share stats and plans as soon as they are available.

[Croydon]

Since the Conan msvc compiler is supposed to eventually replace the Visual Studio one (because VS is an IDE, not a compiler), the discussion here should not be about "additional configurations", but rather WHEN to make the switch to the new msvc Conan model and if for some time CCI is supporting both to ease the transition.

It would also be possible to add the compiler version of VS 2022 only as msvc and leave the current Visual Studio configurations that CCI builds untouched.

[dmn-star]

What will clang-cl integration look like? So far I don't see any way to use clang-cl as a standalone compiler only in conjunction with "Visual Studio" one.

[jgsogo]

What will clang-cl integration look like? So far I don't see any way to use clang-cl as a standalone compiler only in conjunction with "Visual Studio" one.

When we add a new configuration, we don't do anything special. ConanCenter is designed to work with Conan defaults, so whatever we do it should work out-of-the-box with it. We would just define the profile for msvc and run conan create/conan install --build with that profile, if there is any blocker or failure it should be addressed first in the Conan client.

Regarding recipes, whenever we add a new configuration we need to do it very carefully. Many recipes are not prepared for that new configuration and they need to be fixed. So we need to start adding that new configuration taking into account the order of dependencies for the full graph. It is not easy. It can take several weeks or more if many recipes need to be adapted.

[dmn-star]

If you plan to add VS2022 only as msvc (see #6155 (comment)), then it must also be possible to define clang_cl as a standalone compiler. Or there should be a possibility to define compiler as clang and and then use a CL driver.

[jgsogo]

Now that VS 2022 has been released, and together with the help of epochs it should take so long to add this new compiler. Conan uses msvc as default for VS2022, so the sooner we start to support it, the easier it will be to move those recipes forward and add the new configuration.

[SpaceIm]

I have only one concern, is msvc versionning stable now in conan client (I'm still confused by the last change: 193 for cl 19.30 😕)?

We'll have to carefully set required_conan_version to match the last breaking changes when their related feature is involved in the recipe.
For example:

• A version check of msvc should require 1.43.0 (breaking change in fixing msvc version model (breaking) conan#10057).
  Moreover, it would be nice to provide a table with corresponding versions to help CCI contributors. Even when you know Visual Studio, its versionning is hard to understand:
  • Visual Studio 2022 <=> Visual Studio 17 (17.X.X) <=> msvc 193 (for cl 19.3X.XXXXX actually, cl is the actual compiler), obvious !.
  • Visual Studio 2019 <=> Visual Studio 16 (16.X.X) <=> msvc 192 (for cl 19.2X.XXXXX)
  • Visual Studio 2017 <=> Visual Studio 15 (15.X.X) <=> msvc 191 (for cl 19.1X.XXXXX)
  • Visual Studio 2015 <=> Visual Studio 14 (14.X.X) <=> msvc 190 (for cl 19.0X.XXXXX)
• 1.33.0 is sufficient for just checking that compiler is msvc or runtime is static/dynamic and runtime_type is Debug/Release (added in Feature/msvc conan#8201).

[SSE4]

I have only one concern, is msvc versionning stable now in conan client (I'm still confused by the last change: 193 for cl 19.30 😕)?

no, it's not stable, msvc compiler is experimental (per https://docs.conan.io/en/latest/reference/config_files/settings.yml.html?highlight=msvc#msvc) and subject to a breaking changes (and changes in versioning already happened in practice, see conan-io/conan#10057).

Moreover, it would be nice to provide a table with corresponding versions to help CCI contributors. Even when you know Visual Studio, its versionning is hard to understand

I agree, table is extremely useful. maybe I'll create a PR to docs.