[question] Should Visual Studio 17.10 require a profile update to 194?

[rconde01]

What is your question?

Using conan 2.3.1 after updating to Visual Studio 17.10 I got:

xapian-core/1.4.19: Apply patch (file): patches/0001-add-msvc-cl-sh.patch
xapian-core/1.4.19: RUN: "/d/cn2/p/b/xapia3765ba94a5201/b/src/configure" --disable-shared --enable-static --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include --datarootdir=${prefix}/res --disable-documentation
conanvcvars.bat: Activating environment Visual Studio 17 - amd64 - winsdk_version=None - vcvars_ver=14.3
[ERROR:vcvars.bat] Toolset directory for version '14.3' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1

I think a update in the profile to 194 fixes it - but then all packages need to be rebuilt. Is this intended?

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @rconde01

Thanks for your question

I think a update in the profile to 194 fixes it - but then all packages need to be rebuilt. Is this intended?

In theory it shouldn't. We have introduced also a fallback in the compatibility.py plugin, so it accepts binaries built with 193 when requesting compiler.version=194, so it should be ok.

[rconde01]

Should I be able to build using 193 in my profile and Visual Studio 17.10?

[memsharded]

Should I be able to build using 193 in my profile and Visual Studio 17.10?

Yes, that is the intent. Conan will define the right version toolset, like v143, version=19.39 to select it (it must be installed in parallel to the latest 19.40).

[memsharded]

Uhmmm, I think I see what you mean, and this could require defining the compiler.update. Because both compiler.version=193 or =194 will map to the same:

set(CMAKE_GENERATOR_TOOLSET "v143" CACHE STRING "" FORCE)

Because without the update it is not possible to dissambiguate what specific version is desired. I'll have a look at this tomorrow with the team.

[rconde01]

So reading https://devblogs.microsoft.com/cppblog/msvc-toolset-minor-version-number-14-40-in-vs-2022-v17-10/

it seems like I can install the sxs toolset. But I guess the post seems to imply I shouldn’t have to. 193 should potentially map to 143. It’s confusing :(

[memsharded]

I have been trying to use simultaneously the 14.39 and 14.40 toolsets, and so far I have not been able to do it:

• When updating to 17.10, Visual will remove 14.39 and install 14.40 toolset. It works for compiler.version=194 but fails for compiler.version=193, as expected
• If I install back the 14.39 toolset besides the 14.40, then Visual will make it the default, so it will be used even if I am specifying compiler.version=194, because as it maps to toolset=v143 and Visual decides to use 14.39 instead of the latest 14.40, it is wrong.
• Removing 14.39 makes again 14.40 the default and usable
• If I try to use an older update like -s compiler.version=193 -s compiler.update=8 then it maps to CMAKE_GENERATOR_TOOLSET=v143,version=14.38 and it works fine (but with some Visual new warnings regarding some vc .props files, quite weird)

I'd say that this change in the versioning scheme was also complicated for Microsoft themselves and the installation and update of VS toolsets is still not very stable.

[memsharded]

With -c tools.cmake.cmaketoolchain:generator=Ninja it works perfectly (via vcvars), I can create binaries for:

• -s compiler.version=194 => 1940 (maps to latest 194)
• -s compiler.version=193 => 1939 (maps to latest 193, all correct)
• -s compiler.version=193 -s compiler.update=8 => 1938
• -s compiler.version=194 -s compiler.update=0 => 1940

It seems the conjunction with cmake + VS generator (I am using latest CMake 3.29.3)

[memsharded]

I'd say the problem is in CMake, it will not use 14.40 toolset when defined CMAKE_GENERATOR_TOOLSET=v143 and it probably should, conditioned just on the installation order of Visual Studio installer. I think CMake should pick the latest toolset available (latest version), not the latest chronologically installed.

Also, in the VS installation:

• C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\Microsoft.VCToolsVersion.v143.default.props

<?xml version = "1.0" encoding="utf-8"?> 
<Project ToolsVersion = "4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
  <Import Project="$([System.IO.Path]::GetFullPath($(MSBuildThisFileDirectory)Microsoft.VCRedistVersion.v143.default.props))"/> 
  <PropertyGroup> 
    <VCToolsVersion Condition = "'$(VCToolsVersion)' == ''" >14.39.33519</VCToolsVersion> 
  </PropertyGroup>      
</Project>     

• C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\Microsoft.VCToolsVersion.v143.default.txt

14.39.33519

It is likely that CMake is using these files.

Forcing those 2 files to use the 14.40.YYYYY makes it work (need admin to overwrite the files) But doing that will break:

conan create . -s compiler.version=193 -s compiler.update=9
-- CMAKE_GENERATOR_TOOLSET=v143,version=14.39
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
  No CMAKE_CXX_COMPILER could be found.

But weirdly the previous one

conan create . -s compiler.version=193 -s compiler.update=8

keeps working without issues.

[rconde01]

I'm using ninja - so if I read all that correctly, it seems side-by-side will work for me. I'll give it a try. What a mess! :)

[memsharded]

Total mess :(

I am submitting a PR (draft at this moment) in https://github.com/conan-io/conan/pull/16332, that tries to automate the correct 193X compiler version for VS 17.10 update when using compiler.version=193, but at the moment that doesn't work (CMake fails with Visual Studio generator)

[rconde01]

Oh barf - i didn't think about the fact that even though I am using ninja - my dependencies might not (and it turns out some aren't)...uh, although maybe would have helped if installed x86 (not arm) toolset...let's see....seems to work!

[memsharded]

But you can force the dependencies to use Ninja too with ``tools.cmake.cmaketoolchain:generator=Ninja", have you tried that?

[rconde01]

That's a good note - but I built doxygen from conan center and it was using the visual studio generator and seemed to get 14.39 as expected (using 193 in my profile)...so seems like I don't need to do that?

[memsharded]

That's a good note - but I built doxygen from conan center and it was using the visual studio generator and seemed to get 14.39 as expected (using 193 in my profile)...so seems like I don't need to do that?

The problem is that when installing the 14.39 toolset after the update, it becomes the default. So it will also be used for compiler.version=194, so it is necessary to tweak the Visual Studio installed files above to make it work for 194, and if you do that, then it breaks for 193...

[rconde01]

Ah I see - I don't have any pressing need for 14.40 so it's not a blocker for me at the moment...but good to know.

[risa2000]

Just for the record, I needed to fix this in conan 1.64.1 and come up with this approach: https://github.com/conan-io/conan/compare/release/1.64...risa2000:conan:fix-msvc-vs-1710-compiler What it does is pretty simple. If you want to keep your compiler.version=193 and want transparently use v19.40 compiler version from VS2022 17.10 it will generate augmented conanvcvars.bat with this:

@echo off
set "VSCMD_START_DIR=%CD%"
call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC/Auxiliary/Build/vcvarsall.bat"  amd64 -vcvars_ver=14.3
if "%errorlevel%" NEQ "0" (
call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC/Auxiliary/Build/vcvarsall.bat"  amd64 -vcvars_ver=14.4
)

It will try to honor 193 version (as if there was no VS 17.10) and if it fails it will opportunistically try to call the the init with 14.4 toolset version. This is a patch against conan 1.64.1 but seems to be applicable against develop2.

It has been only tested with CMake with Ninja generator though.

[aurelienrb]

Hello,

I guess you are aware that Conan 1 is also impacted: Conan: Unknown MSVC compiler version [1940]

@risa2000 if I understand correctly a patch in under review to fix this issue for an upcoming 1.64.2 version?

[risa2000]

@aurelienrb According to @memsharded who replied to me in another thread (you can read the discussion here) there is no intention from devs to patch Conan 1. So this was the reason I had to come up with the patch I posted above. I just posted it here for other unlucky souls who got caught by this.

Just to set the expectations about the patch:

1. It targets only CMake generator (as far as I know and tested)
2. It expects the compiler.version in the profile to be set to 193, but will (if VS 17.10 is installed) initialize vcvars toolset 14.4.

The reason why I went with this approach is I did not want to change compiler.version settings in all our projects, nor write some complex logic to mix both, just for "another minor patch". Internally we defined compiler.version=192 to represent builds with VS2019, and compiler.version=193 for builds with VS2022. This is purely our interpretation and I am not saying this is the official Conan policy.

EDIT: On the second thought I believe modifying the patch to handle compiler.version=194 might be trivial.

[aurelienrb]

Thanks for the details.

If I understand correctly, toolset v144 is binary compatible with v143 and it is therefore possible (acceptable) to trick Conan to use 194 by making it believe it is 193, is it correct?

[memsharded]

Depending on what you mean, toolset v144 does not exist like that, it is CMAKE_GENERATOR_TOOLSET v143,version=14.4X

[risa2000]

@aurelienrb

If I understand correctly, toolset v144 is binary compatible with v143 and it is therefore possible (acceptable) to trick Conan to use 194 by making it believe it is 193, is it correct?

From what Microsoft says on the topic (I copy the links I posted on the other thread as well): https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170 Another nice summary is here https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B

My understanding is that from VS 2015 the binaries (toolchains) are compatible. I suggest you read the original discussion I posted the link to above for the detail and why I came up with this conclusion.

It however seems that some 3rd party tools (Conan one of them) have devised some other logic how to define binary compatibility and they got caught up in the midst when Microsoft ran out of minor versions.

[risa2000]

Depending on what you mean, toolset v144 does not exist like that, it is CMAKE_GENERATOR_TOOLSET v143,version=14.4X

According to Microsoft, (see here) there are following distinguished versions:

Platform toolset: currently v143 MSVC toolset: currently v14.40 Compiler version: currently v19.40....

In order to initialize "Development environment" (e.g. VCVARS environment) one should call a batch file vcvarsall.bat (installed with the VS), with a parameter -vcvars_ver=14.4 (see the batch listed in my previous post).

This is super confusing (made by Microsoft), because the version here does not refer to the "platform toolset" but "MSVC toolset" and should not be 14.4 but 14.40. I guess someone at MS wanted to save one char and abbreviated it to 14.x. Or they originally wanted to tie the platform toolset version to MSVC toolset version in some version abbreviated scheme as well. What is confusing that the three digit notation may suggest that it refers to "platform toolset" version, which it does not.

Another unfortunate consequence is that the MSVC toolset version seems to be directly related to compiler version, so since the minor version got bumped from 19.39 to 19.40 and the minor version .40 got transferred to the MSVC toolset version as 14.40 and this got abbreviated along the way to 14.4 for the purpose of vcvarsall.bat script we have suddenly a "new" MSVC toolset version - and no one knows why.

@memsharded I would suggest using Microsoft nomenclature for defining the Conan policies instead of the one from CMake, as they seem might get caught exactly in the same (wrong) interpretation of all different Microsoft versions.

[aurelienrb]

Thanks for your details.

I am usually well aware of these kind of MSVC details but here I am a bit confused and it seems I'm not the only one 😄

I discovered the error this morning and rolled back the update in panic mode to avoid spreading the issue to the entire team. I'll take soon more time to investigate.

But what I just realized is the error in my case does not come from Conan but from conan.cmake file: indeed, the way our projects work is as follows:

• a .bat file is used to enable vcvars64.bat, call cmake and open the generated VC++ solution once completed
• our main CMakeLists starts by invokes Conan via the conan.cmake wrapper
• and then include(conan_toolchain.cmake) before continuing

and in the conan.cmake file, I can find this code:

    elseif(NOT MSVC_VERSION VERSION_LESS 1930 AND MSVC_VERSION VERSION_LESS 1940)
        set(${result} 17 PARENT_SCOPE)
    else()
        message(FATAL_ERROR "Conan: Unknown MSVC compiler version [${MSVC_VERSION}]")
    endif()

I guess this code is wrong as well

[memsharded]

elseif(NOT MSVC_VERSION VERSION_LESS 1930 AND MSVC_VERSION VERSION_LESS 1940)

The change to update this to 1950 has been merged this morning to the develop branch of the cmake-conan repo.

[risa2000]

@aurelienrb We are using CMakeToolchain and CMakeDeps generators in our conanfile.py(s) (with Conan 1) and what gets generated by this workflow during conan install is a conanvcvars.bat file which is called in the context of processing conan build command.

@echo off
set "VSCMD_START_DIR=%CD%"
call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC/Auxiliary/Build/vcvarsall.bat"  amd64 -vcvars_ver=14.3

So the failure mode I experience is slightly different from yours and I guess my patch will not work for you (I assume you are using some other CMake generator.)

[aurelienrb]

Thanks @memsharded for the update

@risa2000 We are using CMakeToolchain and CMakeDeps. In theory we are ready to switch to Conan 2 at the recipe level. What prevents us to do so is our use of the legacy conan.cmake. Indeed, the new approach requires to review and update the way we build our projects. This work was planned for the end of the year, so finding a quick fix until then would be great.

[risa2000]

@aurelienrb I am not sure from where conan.cmake comes then. My workflow does not produce this file, only conan_toolchain.cmake which is used in subsequent cmake invocations. Also the initialization of the environment looks different.

[aurelienrb]

@aurelienrb I am not sure from where conan.cmake comes then.

It comes from here: https://github.com/conan-io/cmake-conan

It is a CMake utility script that allows to find & run Conan from CMake. We currently use if to call Conan from CMake that way:

conan_cmake_run(
    NO_LOAD
    CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES}
    BUILD missing
    SETTINGS compiler.cppstd=20
)

[memsharded]

@aurelienrb have you read https://github.com/conan-io/cmake-conan?

cmake-conan for Conan 2 with CMake providers is already more stable and recommended than the legacy Conan 1.X. It is already used in the CLion IDE integration, for example.

[memsharded]

This ticket was marked to be closed by https://github.com/conan-io/conan/pull/16332, with the introduction of a tools.microsoft:msvc_update new conf, that allows to explicitly set the update even for compiler.version=193 with the VS 17.10 update.

I am closing this ticket as resolved in Conan 2.3.2 if there are some further questions about cmake-conan or any pending issues, please create a new ticket. Thanks!