[question] Should Visual Studio 17.10 require a profile update to 194? about conan HOT 38 CLOSED

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

from conan.

@memsharded
I could create a new ticket but let's use this one to clarify what I mean first before creating another confusion.

The most naive way to get hit by this minor version change in VS 17.10 is simply by updating from the previous version (17.9). By doing this update the user is suddenly left with the "new" v14.40 MSVC Toolset, which is to be expected. I doubt anyone updates a whole VS and still wants to use the old toolset.

In such a situation having an option to override a "subminor" digit in a toolset version, which is as I read your fix, is irrelevant. And the question which is written in the title of this issue:
Should Visual Studio 17.10 require a profile update to 194?
still remains.

There are only two (obvious) answers:

• Yes it should - the consequence would be creating a package incompatibility with packages with compiler.version=193
• No it should not.

While the first answer and its consequences are pretty straightforward, the second one might need a more explanation.
This answer is basically saying I do not think the difference between compilers in v14.39 and v14.40 toolsets justifies breaking package binary compatibility and I want for all the binary compatibility purposes the conan package build behave with the new toolset (v14.40) as binary compatible with with the previous toolset (v14.39).

There are two ways (at the conan user level) to address it:

• Either by allowing a user to specify compiler.version=194 in the profile, but provide another means (configuration option) to make sure that conan will take both compiler versions as equal, or
• Allow a user to keep compiler.version=193 in the profile, but gracefully work with v14.40 toolset (again possibly controlled by a configuration option).

I am not saying one is better than the other (in general) but in my case I felt the second option was far less intrusive and kept to the notion we kind of defined internally - VS2019 = compiler.version=192, VS2022 = compiler.version=193).

I believe that I am actually in the "right" issue and that your fix is addressing something else, but you claim this one to be fixed an want to open a new issue. Based on what I wrote above, how should I describe the new issue?

from conan.

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.

from conan.

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

from conan.

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).

from conan.

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.

from conan.

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 :(

from conan.

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.

from conan.

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)

from conan.

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.

from conan.

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! :)

from conan.

Total mess :(

I am submitting a PR (draft at this moment) in #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)

from conan.

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!

from conan.

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

from conan.

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?

from conan.

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...

from conan.

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.

from conan.

Just for the record, I needed to fix this in conan 1.64.1 and come up with this approach:
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.

from conan.

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?

from conan.

@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.

from conan.

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?

from conan.

@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.

from conan.

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.

from conan.

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

from conan.

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.

from conan.

@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.)

from conan.

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.

from conan.

@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.

from conan.

@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
)

from conan.

@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.

from conan.

This ticket was marked to be closed by #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!

from conan.

@memsharded Thanks I'll make a test with Conan 2

from conan.

@memsharded Hey.

Thanks for the fix!
Do you have plans to get it into Conan 1.x as well? If not, I can prepare the patch myself of course, just wanted to make sure it's not already in progress.

from conan.

Do you have plans to get it into Conan 1.x as well? If not, I can prepare the patch myself of course, just wanted to make sure it's not already in progress.

It is not in progress, and it is not planned at the moment. If you want to give it a try, then we can consider it, but please note that this kind of PR to Conan 1 can be a bit risky, and if it has a risk of breaking Conan 1 users, it might not be possible to merge it. Thanks very much for offering to contribute! (recall you need to target the develop branch for such PR to Conan 1)

from conan.

@memsharded @MiKom
Looking at #16332 it seems the patch allows overriding the second digit in MSVC toolset minor version, but not the first one, which is still tied to the last digit of the compiler version (

from conan.

I am wondering which problem did you actually try to fix?

The installation of VS 17.10 removed by msvc 193 installation, breaking also the v14.39 when I re-installed it (at least with CMake+VS generator, it worked well with Ninja). I couldn't chose to use my also installed v14.38, because I couldn't define the update. With that fix, users can perfectly tune which specific update they want in every condition, without necessarily affecting the package_id of every package as compiler.update does.

It was not the one I needed to fix, which is not saying the fix is wrong, but it may not address what some users actually need.

If there is some pending need, it would be better to create a new ticket with full reproducible steps, because this ticket is closed. There are still some edge cases like #16374 (vcvars for LLVM/Clang with msvc backend) that are being addressed, so a reproducible case would help to keep polishing this.

from conan.

I doubt anyone updates a whole VS and still wants to use the old toolset.

On the contrary, I know a lot of users that want more stability, and even if they update their VS they define their compiler.update to guarantee the specific update they use in their packages. When updating VS, if it removes the previous toolset version, they will re-install it back. This used to work without much issues, but now it seems broken by the VS update.

Should Visual Studio 17.10 require a profile update to 194?
still remains.

There are only two (obvious) answers:

Yes it should - the consequence would be creating a package incompatibility with packages with compiler.version=193
No it should not.

Not really. As said above, there are users that do not want to tie their development to the VS update, but to the toolset update.

So the answer, as usual with SW development is "it depends".

If you want to update to the latest toolset version v14.40, then yes, you need to update the profile to compiler.version=194. This is what the Conan profile detection does now.

creating a package incompatibility with packages with compiler.version=193

No, latest Conan introduces a fallback compatibility between compiler.version=194 and compiler.version=193, so this shouldn't be an issue, and it wouldn't be necessary to re-build all binaries with 194 immediately, the previous 193 binaries will be valid.

The changes are already in the compatibility.py default plugin, so if this compatibility is not working, then the report/new ticket should be done against the new compatibility with the fallback from 194 to 193 (actually there is a small issue, already ready for next Conan 2.4 to be released soon).

from conan.

@memsharded

From your last response this seems actually to be the resolution to this issue (and not your patch)

If you want to update to the latest toolset version v14.40, then yes, you need to update the profile to compiler.version=194. This is what the Conan profile detection does now.

Latest Conan introduces a fallback compatibility between compiler.version=194 and compiler.version=193, so this shouldn't be an issue, and it wouldn't be necessary to re-build all binaries with 194 immediately, the previous 193 binaries will be valid.

@MiKom
Just keep it in mind if you are going to port the patch to Conan 1. The compatibility module is not in Conan 1 and the patch will not resolve this issue in Conan 1.

from conan.