Add support for MSVC 2022 series #3988
Comments
|
The Visual Studio versions detected via vswhere and the latest installed VC toolset versions are shown in the table below as of 2021-09-11:
The vc toolset version number for 2022 is 14.30.30423 so 14.3 (v143) is likely correct. SCons vswhere query configuration with 2022 (untested via SCons): Local command-line vswhere command and truncated output: |
|
This looks like good stuff... I'll check it out presently on my local setups, I have a VM with 2022-only, and a full system with several versions installed including 2022. I can't see why the above wouldn't work on a test basis. The question, I guess, is how to handle the period in between now and when 2022 is actually released, so the |
|
I guess we can add a MSVC_CHECK_PRERELEASE variable to add that flag, and add the logic to support the new versions? |
|
I'm a little fuzzy on the details, but I believe the default version of MSVC is the one with the latest/largest version number. This would make a pre-release version of MSVC 14.3 the "default MSVC version". In the current implementation, the "first vswhere query match wins". The release version queries could be added before the pre-release version queries as follows: There would be no maintenance once 14.3 is released. However, there might be unintended consquences if multiple versions of the release editions and pre-release editions are installed at the same time. For example, this would prefer a release version of the Build Tools over a pre-release version of the Community edition. P.S.: I'm not saying this is a good idea. |
|
A working SCons branch with support for VS 2022 is in my GitHub repository at: As discussed above, the prerelease versions are enabled via an environment variable: Notes:
A PR can be issued if desired. |
|
@jcbrill - Please PR. I may have a few minor changes with out MSVC_CHECK_PRERELEASE is implemented, but if you leave the PR such that I can update your branch should be able to get this merged fairly quickly. Also if you can add a blurb in RELEASE.txt that'd be great as well. |
|
This is working for me, but I guess there's some more work pending before closing. I'm going to add the 4.3 milestone, though. |
|
I use Visual Studio 2019 16.11.5 Preview 1 |
|
As of the latest VS2019 update to 16.11.5 on October 12, 2021, it appears that there will be no more updates to the VS2019 Preview version. At this point in time, there seems to be little utility in extending the pre-release detection to VS2019. See the notes below for sources and details. However, your point is taken with respect to VS2022 and VS2022 Preview. I, for one, was unaware that the preview versions continued to be extended after the release version was introduced. The solution in the previous post would work provided VS2022 and VS2020 Preview versions are not installed at the same time. Should instances of VS2022 and VS2022 Preview both be installed at the same time, the preview version would never be chosen. Nor would there be a mechanism to override the "first detected wins" in the current implementation. The environment variable approach (or possibly a command-line argument) is a mechanism to alter the "first detected wins" behavior by ordering the vswhere queries in such a manor to achieve the desired outcome. That said, the implementation as merged into the main branch earlier extends the query list by favoring release versions over pre-release versions when the environment variable is set in the presence of both release and pre-release/preview installations. This made sense when assuming once a production version was released there was no utility in choosing the pre-release/preview version in the presence of both installations. It appears that this assumption could be problematic. One fairly straightforward approach would be to change the query list order to favor preview/pre-release versions over release versions when the environment variable is set. This would allow a preview/pre-release version to be selected in the presence of an installed release version via the environment variable. If the environment variable is not set, the release version would be selected. In this approach, the environment variable should be public, documented, and probably renamed (e.g., SCONS_MSVC_PREVIEW). I would prefer that all SCons public environment variables begin with "SCONS_" but that is a problem for another day. Preview/pre-release versions are not intended for production. The requirement to set an environment variable does not seem that onerous when using a pre-production instance of VS and has the advantage of not requiring any changes to sconscript/sconstruct files when switching between release and preview/pre-release versions. Another alternative would be to add a specific symbol for preview/pre-release versions of VS2022 (e.g., 14.3Pre). This would require changing the value passed to the SCons environment to select a preview/pre-release version. The implementation is likely straightforward given the current version detection implementation. My 2 cents, take it for what its worth. As always, I could be wrong. Visual Studio 2019 Notes:
|
|
@jcbrill - you misunderstood me when I initially suggested that an Environment variable should enable selecting pre-release software. I didn't mean a shell environment variable, but rather SCons' As such no need to prefix such variable with SCONS_ In general SCons should not be controlled by shell's environment.
The last doesn't select the MSVC version to be used, just speeds up detecting the versions available if one can expect no new installations since SCons was last run without it. In general, if you want a specific version you should be explicit about requesting that in your SConstructs. That said at this point none of this is needed for initial MSVC2022 release. So it's probably worthwhile to open a new issue to discuss allowing SCons to select prerelease versions of MSVC explicitly, or as the preferred default (these are two different behavoirs) |
|
@bdbaddog - The code merged in #4030 uses a shell environment variable to enable pre-release versions of VS2022 as described in #4030 (comment) |
Yes. I'm aware. I'll be removing that prior to release. |
|
@bdbaddog - Just a reminder, if you are going to remove the environment variable and the prerelease query prior to release, two minor edits to CHANGES.TXT and RELEASE.TXT are probably necessary as well:
If you would would like me to make the changes, let me know. VS 2022 is being released in 4 days (Nov 8) so there is no harm in excising the prerelease code now. |
|
Thanks for the reminder. I'll make the edits. My revamp plan is to just call vswhere once always with the prerelease flag, and then store the results (vswhere can output json). Then the flag in Environment() would indicate if SCons should consider those items marked pre-release. Hoping to get to this today. |
|
The Visual Studio installer has such an item as an update channel. It is enough to switch from preview to release, and I will receive all updates for the release version, but the studio remains as a preview. Reinstalling the studio for just one module is not an option. |
|
that logic will all go away before release and it will be revamped to better handle prerelease. Choosing a prerelease by default without explicit user request would be against SCons standards. So, firstly that shell env variable will be removed prior to release. Then I'll revamp MSVC detection and have an Environment() variable to allow use of prerelease. |
|
I've done the vswhere to json a couple of different times now both in the scons source tree and as an external stand-alone script. If interested, I could probably find the code snippets. For example, the following function was once added to vc.py after msvc_find_vswhere and before find_vc_pdir_vswhere: def vswhere_query_json(vswhere_args, env=None):
""" Find MSVC instances using the vswhere program.
Args:
vswhere_args: query arguments passed to vswhere
env: optional to look up VSWHERE variable
Returns:
json output or None
"""
if env is None or not env.get('VSWHERE'):
vswhere_path = msvc_find_vswhere()
else:
vswhere_path = env.subst('$VSWHERE')
if vswhere_path is None:
debug("vswhere path not found")
return None
debug('VSWHERE = %s' % vswhere_path)
vswhere_cmd = [vswhere_path] + vswhere_args + ['-format', 'json']
debug("running: %s" % vswhere_cmd)
#cp = subprocess.run(vswhere_cmd, capture_output=True) # 3.7+ only
cp = subprocess.run(vswhere_cmd, stdout=PIPE, stderr=PIPE)
if not cp.stdout:
debug("no vswhere information returned")
return None
vswhere_output = cp.stdout.decode("mbcs")
if not vswhere_output:
debug("no vswhere information output")
return None
try:
vswhere_json = json.loads(vswhere_output)
except json.decoder.JSONDecodeError:
debug("json decode exception loading vswhere output")
vswhere_json = None
return vswhere_jsonSimilarly, to process the json output in my current WIP stand-alone script for processing detected versions (ignore everything that does not apply to internal scons): @classmethod
def vs_process_json_output(cls, vs_rel, vswhere_output, vs_cfg):
msvs_instances = []
for instance in vswhere_output:
#print(json.dumps(instance, indent=4, sort_keys=True))
productId = instance.get('productId','')
if not productId:
debug('productId not found in vswhere output')
continue
installationPath = instance.get('installationPath','')
if not installationPath:
debug('installationPath not found in vswhere output')
continue
installationVersion = instance.get('installationVersion','')
if not installationVersion:
debug('installationVersion not found in vswhere output')
continue
major = installationVersion.split('.')[0]
if major != vs_cfg.vs_major:
raise InternalError('Internal error: msvs major version mis-match: %s, %s' % (major, vs_cfg.vs_major))
component_id = productId.split('.')[-1]
if component_id not in vs_cfg.vs_products:
debug('ignore component_id:%s' % component_id)
continue
component_rank = _VSDetectConst.MSVC_COMPONENTID_SELECTION_RANKING.get(component_id,0)
if component_rank == 0:
# JCB|TODO: exception and/or stderr?
debug('unknown component_id:%s' % component_id)
continue
isPrerelease = 1 if instance.get('isPrerelease', False) else 0
isRelease = 0 if isPrerelease else 1
vs_root = _VSDetectUtil.process_path(installationPath)
if vs_root in vs_rel.msvs_roots:
continue
vs_rel.msvs_roots.add(vs_root)
msvs_base = MSVSBase._factory(
title = vs_cfg.vs_title,
root_dir = vs_root,
root_version = installationVersion,
vc_release = isRelease,
vc_version = vs_cfg.vc_version,
vc_runtime = vs_cfg.vc_runtime,
vc_component_id = component_id,
vc_component_rank = component_rank,
)
msvs_instance = MSVSInstance._factory(
msvs_base = msvs_base,
vs_dir = vs_root,
vs_version = installationVersion,
vs_executable = _VSDetectUtil.vs_executable(vs_root, vs_cfg.vs_executable),
vs_script = _VSDetectUtil.vs_batchfile(vs_root, [vs_cfg.vs_batchfile]),
vs_script_errs = vs_cfg.vs_script_errs,
vs_environ_vars = vs_cfg.vs_environ_vars,
vs_preserve_vars = vs_cfg.vs_preserve_vars,
)
msvs_instances.append(msvs_instance)
msvs_instances = sorted(msvs_instances, key=cmp_to_key(MSVSInstance._default_order))
return msvs_instancesThe above is from a WIP stand-alone script that does MSVS detection for all versions from 6.0 to 14.3 and builds a data structure for all toolsets and individual tools. On my current box, it detects 17 installed instances of VS/VC, 30 toolsets, and 170 individual tools. It might save you some time just by seeing how not to do it :) Happy to share, let me know. |
|
Adding this content here is not ideal. Lemme create another issue. |
|
Please move ongoing discussion to Issue #4048 |
|
Should we close? |
|
MSVC2022 support will be in next release. Enhancements beyond that (more flexible selection of actual compiler,etc) will come later. |
|
Should add that the preview channel request remains tracked in the issue linked above (#4048) |
Visual Studio 2022, which wraps the 17.x compiler series and an unknown toolset versions (v142 is still listed as "latest", that's the one that came with VS 2019/16.x) is in preview now. SCons will need some work to support it, since it has to know some things at least about version numbers.
Note for development during pre-release period -
vswhere, which SCons relies on for recent compilers, will not report unreleased versions without the-prereleaseswitch.The text was updated successfully, but these errors were encountered: