Skip to content

STARSTEER-28862 Build with VS 2026 toolchain (MSVC 14.51.36231, SDK 10.0.26100.0) - #59

Merged
Shkarlatov merged 3 commits into
rogii-v3.12.14from
dev-rogii-v3.12.14
Oct 12, 2026
Merged

Shkarlatov merged 3 commits into
rogii-v3.12.14from
dev-rogii-v3.12.14

Conversation

@d-rotanov-rogii

Copy link
Copy Markdown

Related to STARSTEER-28862 · StarSteer MR !19254

Why: StarSteer moves to Visual Studio 2026 (MSVC 14.51.36231, Windows SDK 10.0.26100.0); every toolset-bound CNPM package is rebuilt with the same compiler, and this branch is the source of that build.
Changed: toolset pin in rogii/msvs_versions.cmake (2022/14.42.34433/10.0.22621.0 → 18/14.51.36231/10.0.26100.0); PCbuild/python.props + pythoncore.vcxproj: VS 2026 toolset selection ported from upstream (VisualStudioVersion 18.0 → PlatformToolset v145, pythonGH-138980/pythonGH-144680); rogii/package.cmake: Python::legacy gets a Windows location (python3.dll/.lib) so the CMake 4.x File API in the VS 2026 IDE does not fail.
Package: python 3.12.14 build 50 sdk26100_vsbt18 — Jenkins CPython-any-branch #50 (#49 intermediate); pinned in StarSteer cmake/environment_windows.cmake; also consumed by Boost 1.91.0 build 35 (Boost.Python).
Verified: package file set matches the previous build; StarSteer builds and passes unit tests and autotests with it (details in STARSTEER-28862).
Merge: part of the VS 2026 batch — merge together with StarSteer !19254 (StarSteer first); merge commit, no squash.

… (python3.dll/python3.lib) so CMake 4.x File API (VS 2026 IDE) does not fail on the imported target
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants