fix for msvc toolset version overflow #15588

memsharded · 2024-02-02T20:57:43Z

Changelog: Fix: Fix for future msvc toolset version overflow
Docs: Omit

jcar87

Reading the Microsoft blog post, I interpret a new compiler version that would be "194" ? https://devblogs.microsoft.com/cppblog/msvc-toolset-minor-version-number-14-40-in-vs-2022-v17-10/

If that is the case, there would be further implications, e.g.:

https://github.com/conan-io/conan/blob/develop2/conan/tools/microsoft/visual.py#L62 - here 194 should also map to '17` ?
But here: https://github.com/conan-io/conan/blob/develop2/conan/tools/microsoft/visual.py#L78 - 194 is actually part of v143
May need to revisit the code here as well:

conan/conan/tools/microsoft/visual.py

Line 315 in 748b417

def _vcvars_vers(conanfile, compiler, vs_version):

- when the compiler is this newer version, we need to pass 14.40 to vcvars

Note that if I read the following right, conan profile detect will detect it as compiler.version=194:

conan/conan/internal/api/detect_api.py

Line 434 in 748b417

version = f"{version_regex.group('major')}{version_regex.group('minor')[0]}"

conans/test/unittests/tools/cmake/test_cmaketoolchain.py

memsharded · 2024-03-22T14:40:19Z

@jcar87 I have proposed a full compiler.version=194 => VS 17 2022 mapping, please review and lets discuss

RubenRBS · 2024-04-17T17:41:36Z

conans/client/conf/__init__.py

@@ -101,7 +101,7 @@
        exception: [null, dwarf2, sjlj, seh]  # Windows MinGW
        cppstd: [null, 98, gnu98, 11, gnu11, 14, gnu14, 17, gnu17, 20, gnu20, 23, gnu23]
    msvc:
-        version: [170, 180, 190, 191, 192, 193]
+        version: [170, 180, 190, 191, 192, 193, 194]
        update: [null, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9]


Are we not missing update values then if it can go higher than 10? Or am I not seeing something?

Conan msvc.update is the compiler update, not the IDE update. In that sense it is just and added version number to 193+update, 194+update, and it cannot be 10. So IDE 17.10 (ide version 10, update 10) => msvc 1940 (version=194, update=0)

Ohh, it's not the IDE one, makes sense now :) ty!

Yep, it seems the best we can do with the MSVC change of versioning approach.

Nekto89 · 2024-05-03T08:51:40Z

I've tried this branch locally with VS2022 Update 10 Preview 6 + CMake 3.29.2 and it doesn't work

conan install --remote conancenter --requires=sqlite3/3.45.3 --build=sqlite3/3.45.3 -pr:b test_profile -pr:h test_profile

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=17
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.update=0
compiler.version=194
os=Windows
[conf]
tools.cmake.cmaketoolchain:generator=Visual Studio 17 2022

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=17
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.update=0
compiler.version=194
os=Windows
[conf]
tools.cmake.cmaketoolchain:generator=Visual Studio 17 2022


======== Computing dependency graph ========
sqlite3/3.45.3: Not found in local cache, looking in remotes...
sqlite3/3.45.3: Checking remote: conancenter
sqlite3/3.45.3: Downloaded recipe revision 1b6b291b7d3730cef1f0264370964d2c
Graph root
    cli
Requirements
    sqlite3/3.45.3#1b6b291b7d3730cef1f0264370964d2c - Downloaded (conancenter)

======== Computing necessary packages ========
sqlite3/3.45.3: Forced build from source
Requirements
    sqlite3/3.45.3#1b6b291b7d3730cef1f0264370964d2c:a1ba2c5fa80c7ce590ee96bd34de63fd16172f7f - Build

======== Installing packages ========
sqlite3/3.45.3: Sources downloaded from 'conancenter'
sqlite3/3.45.3: Calling source() in D:\conan2s\sqlitcfd8cb20ebdfc\s\src
sqlite3/3.45.3: Unzipping 10.6MB, this can take a while
Unzipping 100 %

-------- Installing package sqlite3/3.45.3 (1 of 1) --------
sqlite3/3.45.3: Building from source
sqlite3/3.45.3: Package sqlite3/3.45.3:a1ba2c5fa80c7ce590ee96bd34de63fd16172f7f
sqlite3/3.45.3: Copying sources to build folder
sqlite3/3.45.3: Building your package in D:\conan2s\b\sqlit36f41fbbdecce\b
sqlite3/3.45.3: Calling generate()
sqlite3/3.45.3: Generators folder: D:\conan2s\b\sqlit36f41fbbdecce\b\build\generators
sqlite3/3.45.3: CMakeToolchain generated: conan_toolchain.cmake
sqlite3/3.45.3: CMakeToolchain generated: D:\conan2s\b\sqlit36f41fbbdecce\b\build\generators\CMakePresets.json
sqlite3/3.45.3: Generating aggregated env files
sqlite3/3.45.3: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
sqlite3/3.45.3: Calling build()
sqlite3/3.45.3: Running CMake.configure()
sqlite3/3.45.3: RUN: cmake -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE="generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="D:/conan2s/b/sqlit36f41fbbdecce/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "D:/conan2s/b/sqlit36f41fbbdecce/b/src/.."
-- Using Conan toolchain: D:/conan2s/b/sqlit36f41fbbdecce/b/build/generators/conan_toolchain.cmake
-- Conan toolchain: CMAKE_GENERATOR_TOOLSET=v144,version=14.40
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
CMake Error at CMakeLists.txt:2 (project):
  Failed to run MSBuild command:

    C:/Program Files/Microsoft Visual Studio/2022/Professional/MSBuild/Current/Bin/amd64/MSBuild.exe

  to get the value of VCTargetsPath:

    MSBuild version 17.10.4+10fbfbf2e for .NET Framework
    Build started 5/3/2024 10:49:18 AM.

    Project "D:\conan2s\b\sqlit36f41fbbdecce\b\build\CMakeFiles\3.29.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(456,5): error MSB8020: The build tools for v144 (Platform Toolset = 'v144') cannot be found. To build using the v144 build tools, please install v144 build tools.  Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [D:\conan2s\b\sqlit36f41fbbdecce\b\build\CMakeFiles\3.29.2\VCTargetsPath.vcxproj]
    Done Building Project "D:\conan2s\b\sqlit36f41fbbdecce\b\build\CMakeFiles\3.29.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "D:\conan2s\b\sqlit36f41fbbdecce\b\build\CMakeFiles\3.29.2\VCTargetsPath.vcxproj" (default target) (1) ->
    (PrepareForBuild target) ->
      C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(456,5): error MSB8020: The build tools for v144 (Platform Toolset = 'v144') cannot be found. To build using the v144 build tools, please install v144 build tools.  Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [D:\conan2s\b\sqlit36f41fbbdecce\b\build\CMakeFiles\3.29.2\VCTargetsPath.vcxproj]

        0 Warning(s)
        1 Error(s)

    Time Elapsed 00:00:00.20


  Exit code: 1



-- Configuring incomplete, errors occurred!

sqlite3/3.45.3: ERROR:
Package 'a1ba2c5fa80c7ce590ee96bd34de63fd16172f7f' build failed
sqlite3/3.45.3: WARN: Build folder D:\conan2s\b\sqlit36f41fbbdecce\b\build
ERROR: sqlite3/3.45.3: Error in build() method, line 159
        cmake.configure(build_script_folder=os.path.join(self.source_folder, os.pardir))
        ConanException: Error 1 while executing

What exactly should be used in profile?
Update compiler.version=193+update 10 also can't be used

ERROR: Invalid setting '10' is not a valid 'settings.compiler.update' value.
Possible values are ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']

memsharded · 2024-05-03T08:58:05Z

I am not sure what would be the issue, Conan seems to be doing the right thing, and using v144 which is the version that Microsoft documents to be used, but for some reason it is not being found? Maybe Microsoft didn't explain this correctly?

ERROR: Invalid setting '10' is not a valid 'settings.compiler.update' value.
Possible values are ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']

Yes, this is expected, 193+10 doesn't exist, it is 194+0 because Conan models the compiler version, not the IDE update version

Nekto89 · 2024-05-03T08:59:10Z

I am not sure what would be the issue, Conan seems to be doing the right thing, and using v144 which is the version that Microsoft documents to be used, but for some reason it is not being found? Maybe Microsoft didn't explain this correctly?

ERROR: Invalid setting '10' is not a valid 'settings.compiler.update' value.
Possible values are ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']

Yes, this is expected, 193+10 doesn't exist, it is 194+0 because Conan models the compiler version, not the IDE update version

in CMake you need to still use v143 for new update
v143,version=14.40 / v143,version=14.40.17.10 / v143,version=14.40.17.10,host=x64

memsharded · 2024-05-03T09:50:59Z

in CMake you need to still use v143 for new update

But that doesn't make sense? Microsoft documented the right toolset is v144, isn't it?

Nekto89 · 2024-05-03T09:55:38Z

in CMake you need to still use v143 for new update

But that doesn't make sense? Microsoft documented the right toolset is v144, isn't it?

memsharded · 2024-05-03T10:06:53Z

Oh, you are right, thanks very much for pointing this!

I have just uploaded a fix, could you please re-try?

Nekto89 · 2024-05-03T12:00:52Z

Oh, you are right, thanks very much for pointing this!

I have just uploaded a fix, could you please re-try?

With fix conan has successfully built sqlite3 with proper toolset compiler.version=194 compiler.update=0

-- Conan toolchain: CMAKE_GENERATOR_TOOLSET=v143,version=14.40
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.40.33808.0

jcar87 · 2024-05-03T12:55:42Z

Thanks for testing @Nekto89

Indeed the compiler with "MSVC toolset 19.40.xxx" is still part of the v143 platform toolset.

@memsharded I think it looks okay now, but I will double check the activation of vcvars, and the ability to force the 193 compiler version when the 19.4 is also available (and would otherwise be picked up by default)

There is another place that is worth looking into:

conan/conan/tools/microsoft/visual.py

Lines 132 to 135 in a56c639

    
           vcvars_ver = {"v140": "14.0", 
        
                         "v141": "14.1", 
        
                         "v142": "14.2", 
        
                         "v143": "14.3"}.get(toolset_version)

The code there parses the compiler.runtime_version setting, which is only optionally when the compiler is clang on Windows - but now we can't disambiguate whether the vcvars need to be for 193 or 194. I would probably consider checking which update is installed and available, and use the most recent? Otherwise, using the 193 runtime should be compatible anyway, so it is the safest choice, but I would then leave a comment.

jcar87 · 2024-05-03T14:13:51Z

conans/client/graph/compatibility.py

+                new_combinations.append(comb)
+        combinations = new_combinations
+
+    conanfile.output.info(f"COMbINATIONS {combinations}")


COMbINATIONS typo here, but maybe consider having both FACTORS and COMBINATIONS not being all caps? Also found it a little confusing, from a user perspective I dont know what factors or combinations are.

jcar87 · 2024-05-03T14:44:52Z

Tested:

conan profile detect detects 194 when the preview is installed ✅
When consuming a package with compiler.version=194, and a binary exists for 193 but not for 194, it falls back to finding the compatible binary: ✅

======== Computing necessary packages ========
zlib/1.3.1: FACTORS [[{'compiler.version': '193'}]]
zlib/1.3.1: COMbINATIONS [{'compiler.version': '193'}]
zlib/1.3.1: Checking 1 compatible configurations
zlib/1.3.1: Main binary package 'bf083199c71b5d660bf9523713b0cd79bc0919fb' missing. Using compatible package 'ea5dc84deb25b32a77ec23c39a1811e3f441ee54': compiler.version=193

Creating a package with compiler.version=194 results in CMake picking up v143 toolset with the 19.40 compiler ❌
What I get instead:

-- Using Conan toolchain: C:/xxx/conan-center-index/recipes/zlib/all/test_package/build/msvc-194-armv8-14-release/generators/conan_toolchain.cmake
-- Conan toolchain: CMAKE_GENERATOR_TOOLSET=v143
-- Conan toolchain: C++ Standard 14 with extensions OFF
-- The C compiler identification is MSVC 19.39.33523.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.39.33519/bin/Hostarm64/arm64/cl.exe - skipped

Here there seem to be multiple factors at play:

the CMakeToolchain generators only appends the version ,version=14.xx when we have compiler.update set. But if we only have compiler.version=194 and no update, we don't provide additional information - leaving CMake to detect its own
In absence of (1), CMake says it chooses a default: https://cmake.org/cmake/help/latest/variable/CMAKE_VS_PLATFORM_TOOLSET_VERSION.html#variable:CMAKE_VS_PLATFORM_TOOLSET_VERSION - it doesn't say it chooses the "latest", only that it chooses a default.
CMake is choosing the VS 17.9 instance, rather than the 17.10 preview - so even if I define the compiler.update setting, it won't find it, unless I also pass CMAKE_GENERATOR_INSTANCE set to C:/Program Files/Microsoft Visual Studio/2022/Preview
It looks like even in Microsoft tools, the "default" for platform toolset 143 is still 19.39 - unsure if this only during the preview, or if I have a bad installation. However I can see evidence that "default" is not always the latest: https://developercommunity.visualstudio.com/t/Default-value-of-MSVC-Toolset-is-not-doc/10398953,

Only when using CMAKE_GENERATOR_INSTANCE so that CMake uses the Visual Studio 2022 Update 10 preview:

Without defining the compiler.update setting, CMake still detects and uses the 19.39 compiler, even if the compiler.version=194
Setting compiler.version=193 and compiler.update=0 AND setting then CMake detects the correct compiler (19.40)

A meson-toolchain recipe seems fine, which also instantiates vcvars:

conanvcvars.bat: Activating environment Visual Studio 17 - amd64_arm64 - winsdk_version=None - vcvars_ver=14.4
[vcvarsall.bat] Environment initialized for: 'x64_arm64'
The Meson build system
Version: 1.2.2

Build type: cross build
..\src\meson.build:1: WARNING: Keyword argument "default_options" defined multiple times.
WARNING: This will be an error in future Meson releases.
Project name: pkgconf
Project version: 2.2.0
C compiler for the host machine: cl (msvc 19.40.33808 "Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33808 for ARM64")
C linker for the host machine: link link 14.40.33808.0
C compiler for the build machine: cl (msvc 19.40.33808 "Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33808 for ARM64")
C linker for the build machine: link link 14.40.33808.0

jcar87 · 2024-05-03T14:59:21Z

if my understanding is correct, there are some scenarios

A user that has side-by-side installations of VS2022 and VS2022.10 preview:

A) User runs `conan profile detect`

conan profile detect will detect compiler.version=194
But CMake will not even consider the preview installation, and will use the 19.3x compiler regardless (with no error) - all binaries still work, but it's not the newer compiler - this is wrong

B) User still has a profile with `compiler.version=193`

Everything works fine, both CMake and conan profile "agree"

C) User has a profile with `compiler.version=194` and `compiler.update=0`

CMake will fail.

User only has Visual Studio 2022.10 preview installed OR tells cmake which installation to use via `CMAKE_GENERATOR_INSTANCE`

A) User runs `conan profile detect`

conan profile detect will detect compiler.version=194
CMake detects the preview installation, but still picks up the 19.3x compiler - this seems to be the current default set in Visual Studio altogether - everything builds and works, but it's not using the 19.4x compiler

B) User has a profile with `compiler.version=194` and `compiler.update=0`

This works fine - Conan passes v143,version=14.40 as the generator toolset, and it uses the new compiler version.

C) User still has a profile with `compiler.version=193`

This is "correct" - since CMake uses the 19.3x MSVC toolset by default, however, if upon release it moves to use 19.4x instead, then this would be wrong.

As it stands, I wouldn't merge this PR - all the right things are there, but

conan profile detect assumes compiler.version=194 if Update 10 is installed - but unsure it is the default version
If the Preview is installed side by side with a released version, CMake defaults to the release
If preview is installed on its own or we tell CMake to use it, CMake still picks up the 19.3x toolset in the abscence of compiler.update being defined.

All the right things are there - but at the moment if the update 10 is using the 19.3x toolset as the default, nothing is wrong - I would reassess on release

see comments

Nekto89 · 2024-05-03T15:06:04Z

* If preview is installed on its own or we tell CMake to use it, CMake _still_ picks up the 19.3x toolset in the abscence of `compiler.update` being defined.

What do you mean by this? I just checked without conan

cmake -G"Visual Studio 17 2022" -Tv143 ..
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.40.33808.0

VC\Auxiliary\Build\Microsoft.VCToolsVersion.v143.default.txt and .props contain latest 14.40.33807. Same for Microsoft.VCToolsVersion.default.txt

jcar87 · 2024-05-03T15:41:00Z

Hi @Nekto89 thanks for following up. Could you paste the bit of the CMake configuration log where it prints the location of cl.exe?

On my machine in that directory C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Auxiliary\Build
some contain 14.40, but some point to 14.39, and CMake uses 14.39 (and I've not touched any of these files)

Nekto89 · 2024-05-03T17:25:09Z

Hi @Nekto89 thanks for following up. Could you paste the bit of the CMake configuration log where it prints the location of cl.exe?

On my machine in that directory C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Auxiliary\Build some contain 14.40, but some point to 14.39, and CMake uses 14.39 (and I've not touched any of these files)

cmake -G"Visual Studio 17 2022" ..
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.40.33808.0
-- The CXX compiler identification is MSVC 19.40.33808.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (8.2s)
-- Generating done (0.0s)

cmake -G"Visual Studio 17 2022" -Tv143 ..
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.40.33808.0
-- The CXX compiler identification is MSVC 19.40.33808.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (8.1s)
-- Generating done (0.1s)

cmake -G"Visual Studio 17 2022" -Tv143,version=14.40 ..
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.40.33808.0
-- The CXX compiler identification is MSVC 19.40.33808.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (7.9s)
-- Generating done (0.0s)

cmake -G"Visual Studio 17 2022" -Tv143,version=14.40.17.10 ..
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.40.33808.0
-- The CXX compiler identification is MSVC 19.40.33808.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (7.7s)
-- Generating done (0.0s)

I don't have 14.39 on my machine. It was automatically updated to 14.40. I've also explicitly added 14.40 in VS Installer.

memsharded · 2024-05-05T21:16:28Z

Some more info:

It seems CMake has some understanding somwhere of v144: https://gitlab.kitware.com/cmake/cmake/-/commit/d2df2e94e50a003fc635a1913f70ccc784696f15
Some others seems to have the notion of v144 too: xmake-io/xmake@f626872

jcar87 · 2024-05-06T18:26:24Z

Thanks @Nekto89! I've been doing more troubleshooting using the Windows Sandbox

Visual Studio Installer for 17.9.6 : -> 14.40 does not show as an option (as expected)
Visual Studio Installer for 17.10.0 preview 6.0 -> leaving the default to "latest" will install the 14.40 MSVC toolset and that will be correctly picked up by both CMake and MSBuild - note that from what I can see CMake picks this up only if the "preview" is the only version of Visual Studio installed (having 17.9 AND the preview, 17.9 seems to take priority)
Visual Studio Installer for 17.10.0 preview 6.0 -> but selecting the 14.39 toolset as well as the the 14.40 one - that's where I was having issues. This actually seems to be a bug: https://developercommunity.visualstudio.com/t/MicrosoftVCToolsVersionv143defaulttx/10041951#T-N10601904 - where the .default.txt file gets overwritten by all v143 variants, so only one stands (presumably the one that was last installed?). This would also explain the inconsistency I was seeing (some files were pointing to 14.40, some to 14.39), and this is why both CMake and MSBuild were using 19.39 as the default instead of 14.40 which was available (and was more recent)

@memsharded - I think this was just a fluke with my installation and a manifestation of that visual studio installer bug - I think we can assume that both a clean install of the new version, or an upgrade, will be correctly configured to use 14.40 as the "msvc toolset" version. This is really only an issue of users rely on conan profile detect (because we don't necessarily derive the default version in the same way that CMake does), or if a user explicitly sets the profile to compiler.version=194

As for the v144: it doesn't exist as a platform toolset and so far never has. This PR https://gitlab.kitware.com/cmake/cmake/-/commit/d2df2e94e50a003fc635a1913f70ccc784696f15 from CMake is a bit confusing at first, but it makes sense, what they were doing was a mapping where if a user passed version=14.39.xx to CMAKE_GENERATOR_TOOLSET, without specifying the platform toolset, CMake would then deduce the "platform toolsetversion from the first 3 digits tov143- that logic would have a "bug" if a user provided14.40.xxbecause it would've then chosenv144which doesn't exist, and it needs to be mapped tov143(essentially, similar logic to what we have in our PR, it just looks confusing to seev144` in text). The xmake changes are confusing in what they call a "toolset version", so it's probably a misnomer, but then again the naming conventions are confusing on their own

fix for msvc toolset version overflow

68074ef

memsharded added this to the 2.1 milestone Feb 2, 2024

memsharded requested review from jcar87 and RubenRBS February 5, 2024 09:59

memsharded assigned czoido Feb 5, 2024

memsharded marked this pull request as ready for review February 5, 2024 09:59

jcar87 reviewed Feb 5, 2024

View reviewed changes

conans/test/unittests/tools/cmake/test_cmaketoolchain.py Outdated Show resolved Hide resolved

memsharded modified the milestones: 2.1, 2.2 Feb 7, 2024

memsharded modified the milestones: 2.2.0, 2.3.0 Mar 15, 2024

memsharded added 2 commits March 22, 2024 15:24

review

78ad98e

review

fb9bbe6

memsharded requested a review from jcar87 March 22, 2024 14:39

wip

ebe0442

This was referenced Mar 22, 2024

[feature] Support new msvc versioning for VS2022 latest toolsets #15583

Open

conan.tools.microsoft.VCVars generator does not follow settings.compiler.update #15522

Closed

memsharded marked this pull request as draft March 25, 2024 18:20

memsharded added the type: look into label Mar 25, 2024

merged develop2

a55e950

memsharded marked this pull request as ready for review April 15, 2024 11:32

memsharded added 3 commits April 17, 2024 17:29

Merge branch 'develop2' into fix/msvc_toolset_version_overflow

ff167ad

compatibility

8839620

compat only forward

704b454

RubenRBS reviewed Apr 17, 2024

View reviewed changes

czoido approved these changes Apr 18, 2024

View reviewed changes

solved conflicts

e06076b

jcar87 previously approved these changes May 3, 2024

View reviewed changes

memsharded added 2 commits May 3, 2024 12:03

Merge branch 'develop2' into fix/msvc_toolset_version_overflow

9dc624f

fixes

a56c639

memsharded removed the type: look into label May 3, 2024

jcar87 reviewed May 3, 2024

View reviewed changes

memsharded modified the milestones: 2.3.0, 2.4.0 May 6, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix for msvc toolset version overflow #15588

fix for msvc toolset version overflow #15588

memsharded commented Feb 2, 2024 •

edited

jcar87 left a comment •

edited

memsharded commented Mar 22, 2024

RubenRBS Apr 17, 2024

memsharded Apr 17, 2024

RubenRBS Apr 17, 2024 •

edited

memsharded Apr 17, 2024

Nekto89 commented May 3, 2024 •

edited

memsharded commented May 3, 2024

Nekto89 commented May 3, 2024

memsharded commented May 3, 2024

Nekto89 commented May 3, 2024

memsharded commented May 3, 2024

Nekto89 commented May 3, 2024

jcar87 commented May 3, 2024

jcar87 May 3, 2024

jcar87 commented May 3, 2024

jcar87 commented May 3, 2024

Nekto89 commented May 3, 2024 •

edited

jcar87 commented May 3, 2024 •

edited

Nekto89 commented May 3, 2024 •

edited

memsharded commented May 5, 2024

jcar87 commented May 6, 2024 •

edited

fix for msvc toolset version overflow #15588

Are you sure you want to change the base?

fix for msvc toolset version overflow #15588

Conversation

memsharded commented Feb 2, 2024 • edited

jcar87 left a comment • edited

Choose a reason for hiding this comment

memsharded commented Mar 22, 2024

RubenRBS Apr 17, 2024

Choose a reason for hiding this comment

memsharded Apr 17, 2024

Choose a reason for hiding this comment

RubenRBS Apr 17, 2024 • edited

Choose a reason for hiding this comment

memsharded Apr 17, 2024

Choose a reason for hiding this comment

Nekto89 commented May 3, 2024 • edited

memsharded commented May 3, 2024

Nekto89 commented May 3, 2024

memsharded commented May 3, 2024

Nekto89 commented May 3, 2024

memsharded commented May 3, 2024

Nekto89 commented May 3, 2024

jcar87 commented May 3, 2024

jcar87 May 3, 2024

Choose a reason for hiding this comment

jcar87 commented May 3, 2024

jcar87 commented May 3, 2024

A user that has side-by-side installations of VS2022 and VS2022.10 preview:

A) User runs conan profile detect

B) User still has a profile with compiler.version=193

C) User has a profile with compiler.version=194 and compiler.update=0

User only has Visual Studio 2022.10 preview installed OR tells cmake which installation to use via CMAKE_GENERATOR_INSTANCE

A) User runs conan profile detect

B) User has a profile with compiler.version=194 and compiler.update=0

C) User still has a profile with compiler.version=193

Nekto89 commented May 3, 2024 • edited

jcar87 commented May 3, 2024 • edited

Nekto89 commented May 3, 2024 • edited

memsharded commented May 5, 2024

jcar87 commented May 6, 2024 • edited

memsharded commented Feb 2, 2024 •

edited

jcar87 left a comment •

edited

RubenRBS Apr 17, 2024 •

edited

Nekto89 commented May 3, 2024 •

edited

A) User runs `conan profile detect`

B) User still has a profile with `compiler.version=193`

C) User has a profile with `compiler.version=194` and `compiler.update=0`

User only has Visual Studio 2022.10 preview installed OR tells cmake which installation to use via `CMAKE_GENERATOR_INSTANCE`

A) User runs `conan profile detect`

B) User has a profile with `compiler.version=194` and `compiler.update=0`

C) User still has a profile with `compiler.version=193`

Nekto89 commented May 3, 2024 •

edited

jcar87 commented May 3, 2024 •

edited

Nekto89 commented May 3, 2024 •

edited

jcar87 commented May 6, 2024 •

edited