MSVC: Remove 32-bit arm target and host from the VS 2026 configuration. #4811
Conversation
Changes: * MSVC: Remove the 32-bit arm target and host from the Visual Studio 2026 configuration. Visual Studio 2026 removed support for targeting arm. The arm libraries are not included in the latest Windows SDK (10.0.26100.0). * Document the potential issue with targeting 32-bit arm using Visual Studio 2022 when Windows SDK 10.0.26100 or later is installed.
|
FYI Targeting 32-bit arm with VS 2022 and the latest Windows SDK installedVisual Studio 2026 removed support for 32-bit arm targets. The 32-bit arm libraries are not included in the latest Windows SDK (10.0.26100.0). The Visual Studio documentation states: "Developers needing to target ARM32 can continue using the Visual Studio 2022 v143 build tools". As of Visual Studio 2022 17.14.23, builds targeting 32-bit arm on a machine that has Windows SDK 10.0.26100.0 or later installed, may fail due to the Visual Studio 2022 batch file implementation. If this happens, explicitly passing an earlier Windows SDK version via Experiment ConfigurationVisual Studio Installations (latest):
Windows SDK Installations (latest):
Test configuration building a simple shared library with VS 2022:
Source file ( SConstruct: Batch File: Output (annotated for missing directories): Comments:
|
|
Haven't looked at this in any detail, but if you can't build for that target, it's hard to argue it should be kept in the 2026-specific parts of the tables... |
|
@mwichmann It might be best to move the update to The way the tables are currently constructed, for each table there may be table entries that are not necessarily valid for all of the VS versions that use the table. The concern with VS2026 is that it is possible to install the v143, v142, v141, and v140 toolsets targeting arm. However, they can't be used from the "main" VS batch file. Perhaps future versions of the installer will remove the options for the older toolsets targeting arm. The installer does not appear to add the arm specific batch files that call the "main" VS batch file which is likely sufficient for SCons even if the toolset proper is installed. There is a difference in behavior between a host/target pair not defined in the table (an unsupported warning eventually followed by the installed versions message) and defined in the table but not found (from memory a toolset not found error). Prior to VS2026, I don't think it was possible to install a toolset that couldn't be used. More information to follow. |
|
@jcbrill - sounds reasonable. If the README file is getting to large and a version specific file make sense, then maybe add README-VS2026 with a not in the main README or change README to README-Pre-2026.. Is this PR otherwise good to go, or wait for more updates? |
|
@bdbaddog Wait for more updates which shouldn't take very long. I'm not sure the tables should be changed. I need to compare the current behavior with the proposed behavior. I think the current behavior might be more desirable. |
|
FYI: msvc batch files and table configurations. Typically, a new table was added when one or more of the following occurred:
Prior to VS 2026, it wasn't necessary to add a new table when a target was dropped because the toolset could not be installed. That is not quite true for VS 2026 but it may not matter pending testing. In the tables below, rows
MSVC batch file symbols and partial internal table configuration:
|
|
In case you missed it, Visual Studio moving to an annual release cycle in November. https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-rhythm:
|
|
@jcbrill hmm |
|
@bdbaddog That was the same sentence that caught my eye as well. I'm not sure what that means. Hopefully, it will show up earlier in the preview/insiders build to assess the impact to SCons before it shows up in the release build. |
|
The results when attempting to build a VS 2026 arm target for the current master branch and this PR are shown below. SConstruct: Current SCons master: This PR: Staying with the current main branch would require fewer tables and possibly less future maintenance. The working host/target script warning message is accurate. Possibly misleading though. For this PR, the first warning message is accurate but the second warning is not particularly helpful. From the tables above, when Options:
I'm leaning towards option 1: not changing the tables as it makes maintenance easier. I have no idea how popular 32-bit arm is as a target for MSVC. Notes:
|
|
@bdbaddog "... that'll have implications for msvc caching as well." It might not have any more implications than already exist in the current implementation. They might just install a new default build tools version and toolset version(s). A new build tool series and toolset is traditionally installed in a versioned directory name. I believe there can be issues today with the current cache implementation when a new toolset is installed but the previous toolset is not uninstalled (i.e., the cache entries are all valid; they are just not the latest). Note: There is an undocumented feature setting that forces the What will be curious is if vswhere will have multiple VS versions with the same installation folder. This might have implications for the definition of |
… moved to PR SCons#4812. [ci skip]
For RELEASE.txt, the text was moved from the FIXES section to the DEVELOPMENT section as this PR is not necessarily a fix or an improvement.
|
This PR is now complete. Based on the earlier behavior of the host/target batch file configuration tables, this PR is not strictly necessary. However, given the Microsoft changes to the release schedule it may not be the worst idea to have a configuration anchored specifically to VS 2026 now. I've been waffling back and forth if this should be included or abandoned. Either way is fine with me. The RELEASE.txt blurb was moved from FIXES to DEVELOPMENT. |
SCons/Tool/MSCommon/vc.py
Outdated
|
|
||
| label = 'GE2026', | ||
|
|
||
| host_all_hosts = OrderedDict([ |
There was a problem hiding this comment.
Is it necessary to use OrderedDict() anymore? Isn't insertion order maintained in all supported python versions?
There was a problem hiding this comment.
For the usage here, OrderedDict is not necessary.
SCons/Tool/MSCommon/vc.py
Outdated
| } | ||
|
|
||
| _GE2022_HOST_TARGET_CFG = _host_target_config_factory( | ||
| _LE2022_HOST_TARGET_CFG = _host_target_config_factory( |
There was a problem hiding this comment.
If this covers only VS2022 can you change var names to _E2022_* ?
There was a problem hiding this comment.
Perhaps the variable names should match the version number range usage?
For example,
_GE2026_* 2026
_LT2026_GE2022_* 2022
_LT2022_GE2017_* 2019, 2017
_LT2017_GE2010_* 2015, 2013, 2012, 2010
_LT2010_GE2005_* 2008, 2005,
_LT2005_* 2003, 2002, 1998 [6.0]
How they are currently used:
if vernum_int >= 145:
# 14.5 (VS2026) and later
host_target_cfg = _GE2026_HOST_TARGET_CFG
elif 145 > vernum_int >= 143:
# 14.3 (VS2022)
host_target_cfg = _LE2022_HOST_TARGET_CFG
elif 143 > vernum_int >= 141:
# 14.2 (VS2019) to 14.1 (VS2017)
host_target_cfg = _LE2019_HOST_TARGET_CFG
elif 141 > vernum_int >= 100:
# 14.0 (VS2015) to 10.0 (VS2010)
host_target_cfg = _LE2015_HOST_TARGET_CFG
elif 100 > vernum_int >= 80:
# 9.0 (VS2008) to 8.0 (VS2005)
host_target_cfg = _LE2008_HOST_TARGET_CFG
else: # 80 > vernum_int
# 7.1 (VS2003) and earlier
host_target_cfg = _LE2003_HOST_TARGET_CFG
if vernum_int >= 145:
# 14.5 (VS2026) and later
batfiledir = os.path.join(pdir, "Auxiliary", "Build")
batfile, _ = _GE2026_HOST_TARGET_BATCHFILE_CLPATHCOMPS[(host_arch, target_arch)]
batfilename = os.path.join(batfiledir, batfile)
vcdir = pdir
elif 145 > vernum_int >= 143:
# 14.3 (VS2022)
batfiledir = os.path.join(pdir, "Auxiliary", "Build")
batfile, _ = _LE2022_HOST_TARGET_BATCHFILE_CLPATHCOMPS[(host_arch, target_arch)]
batfilename = os.path.join(batfiledir, batfile)
vcdir = pdir
elif 143 > vernum_int >= 141:
# 14.2 (VS2019) to 14.1 (VS2017)
batfiledir = os.path.join(pdir, "Auxiliary", "Build")
batfile, _ = _LE2019_HOST_TARGET_BATCHFILE_CLPATHCOMPS[(host_arch, target_arch)]
batfilename = os.path.join(batfiledir, batfile)
vcdir = pdir
elif 141 > vernum_int >= 100:
# 14.0 (VS2015) to 10.0 (VS2010)
arg, batfile, cl_path_comps = _LE2015_HOST_TARGET_BATCHARG_BATCHFILE_CLPATHCOMPS[(host_arch, target_arch)]
batfilename = os.path.join(pdir, "vcvarsall.bat")
depbat = os.path.join(pdir, *cl_path_comps, batfile)
clexe = os.path.join(pdir, *cl_path_comps, _CL_EXE_NAME)
elif 100 > vernum_int >= 80:
# 9.0 (VS2008) to 8.0 (VS2005)
arg, batfile, cl_path_comps = _LE2008_HOST_TARGET_BATCHARG_BATCHFILE_CLPATHCOMPS[(host_arch, target_arch)]
if vernum_int == 90 and MSVC.Kind.msvc_version_is_vcforpython(msvc_version):
# 9.0 (VS2008) Visual C++ for Python:
# sdk batch files do not point to the VCForPython installation
# vcvarsall batch file is in installdir not productdir (e.g., vc\..\vcvarsall.bat)
# dependency batch files are not called from vcvarsall.bat
sdk_pdir = None
batfilename = os.path.join(pdir, os.pardir, "vcvarsall.bat")
depbat = None
else:
batfilename = os.path.join(pdir, "vcvarsall.bat")
depbat = os.path.join(pdir, *cl_path_comps, batfile)
clexe = os.path.join(pdir, *cl_path_comps, _CL_EXE_NAME)
else: # 80 > vernum_int
# 7.1 (VS2003) and earlier
pdir = os.path.join(pdir, "Bin")
batfilename = os.path.join(pdir, "vcvars32.bat")
clexe = os.path.join(pdir, _CL_EXE_NAME)
There was a problem hiding this comment.
How about?
_GE2026_* 2026
_LE2022_GE2022_* 2022
_LE2019_GE2017_* 2019, 2017
_LE2015_GE2010_* 2015, 2013, 2012, 2010
_LE2008_GE2005_* 2008, 2005,
_LE2003_* 2003, 2002, 1998 [6.0]
There was a problem hiding this comment.
If it only covers one version, then EVERSION seeems better than an range which can only be one version? At least less confusing to me... otherwise I have to go google the list of all versions to see which versions fit in that range...
There was a problem hiding this comment.
Acceptable?
_GE2026_* 2026
_EQ2022_* 2022
_LE2019_GE2017_* 2019, 2017
_LE2015_GE2010_* 2015, 2013, 2012, 2010
_LE2008_GE2005_* 2008, 2005,
_LE2003_* 2003, 2002, 1998 [6.0]
* remove OrderedDict * rename batch file configuration variables for the version or range of versions supported.
|
The msvc/msvs tests passed (83) or skipped (3) with python versions 3.7 to 3.14 locally. |
3 participants
Changes:
SCons/Tool/MSCommon/README.rst.Contributor Checklist:
CHANGES.txtandRELEASE.txt(and read theREADME.rst).