Looks good.

The <command>vswhere.exe</command> executable is distributed with
Microsoft Visual Studio and Build Tools since the 2017 edition,
but is also available as a standalone installation.
It allows queries to obtain detailed information about
installations of 2017 and later editions;
with the <option>-legacy</option> argument,
it can return limited information for
installations of the 2010 through 2015 editions.
&SCons; makes use of this information to help determine
the state of compiler support.

The last sentence appears to imply that SCons uses vswhere.exe for 2015 and earlier.

Is there any need to explicitly state that currently SCons only uses vswhere.exe for 2017 and later?

Something along the lines of:

&SCons; makes use of <command>vswhere.exe</command> in determining
the state of compiler support for installations of 2017 and later
editions.

Okay. New info for me... do we actually look at the "limited" information in any situation? Or should I just drop that concept?

do we actually look at the "limited" information in any situation? Or should I just drop that concept?

We do not use the "limited" information. We use the registry for 2015 and earlier and vswhere.exe for 2017 and later.

The current vswhere invocation is effectively vswhere.exe -all -products * -format json -utf8 and is only invoked once.

The current vswhere query does not return preview versions (yet).

I am not sure if there is any value added documenting the legacy version behavior.

A user that wants to use vswhere.exe to get a legacy installation location (.e.g., 2015) presumably already knows how to invoke vswhere.exe to return such information.

@jcbrill - if we decided to move current logic to say "msvclegacy" tool and clean up "msvc",etc tools so they only supported vswhere supported versions. Would that simplify the logic significantly? Or, have a msvc2022, msvc2020, tool per version, would that simplify the logic?

if we decided to move current logic to say "msvclegacy" tool and clean up "msvc",etc tools so they only supported vswhere supported versions. Would that simplify the logic significantly? Or, have a msvc2022, msvc2020, tool per version, would that simplify the logic?

Maybe.

The recently merged PR separated vswhere handling from registry handling. There is a single vswhere query and the registry is only searched once for each version via multiple queries for each version.

As for simplifying the logic there is one function for vswhere and one function for the registry.

Eliminating the registry function would require expanding the vswhere function to determine the "kind" of legacy installation (e.g., Express, BuildTools, Development, etc).

I don't remember how vswhere.exe handles legacy express versions and buildtools (2015) versions. The last series of tests I did for the PR included external vswhere runs including the legacy option. I would need to go back through the results.

if we decided to move current logic to say "msvclegacy" tool and clean up "msvc",etc tools so they only supported vswhere supported versions. Would that simplify the logic significantly? Or, have a msvc2022, msvc2020, tool per version, would that simplify the logic?

Maybe.

The recently merged PR separated vswhere handling from registry handling. There is a single vswhere query and the registry is only searched once for each version via multiple queries for each version.

As for simplifying the logic there is one function for vswhere and one function for the registry.

Eliminating the registry function would require expanding the vswhere function to determine the "kind" of legacy installation (e.g., Express, BuildTools, Development, etc).

I don't remember how vswhere.exe handles legacy express versions and buildtools (2015) versions. The last series of tests I did for the PR included external vswhere runs including the legacy option. I would need to go back through the results.

I was thinking msvc would support 2017+ and not ones where vswhere required -legacy.

I just released there is more to the question that the detection (vswhere/registry). I would need to look at the code as there are special cases in a variety of places and what the tradeoffs would entail.

I'm not sure I would make it a high priority in the short term.

The biggest reason that it is difficult to implement preview versions is that there is no msvc internal data structure. The vs and sdk (I think) keeps detected information data structures. An internal data structure for msvc installations/toolsets/tools built during detection makes selection quite a bit easier. It would also allow direct installation queries for all versions of msvc.

This is the biggest reason that the other [WIP] MSVC detection branch will be abandoned. In addition to the detection changes there was a significant amount of changes to support the internal data structure which snowballed.

I was thinking msvc would support 2017+ and not ones where vswhere required -legacy.

AFAIK, there really isn't much in the msvc tool proper that is version specific. Not sure about mslink or mslib.

The MSCommon code (vc.py, vs.py) is a different story.

I was thinking msvc would support 2017+ and not ones where vswhere required -legacy.

AFAIK, there really isn't much in the msvc tool proper that is version specific. Not sure about mslink or mslib.

The MSCommon code (vc.py, vs.py) is a different story.

Yes. I consider that part of msvc. So that's what I'm talking about.

Okay, I'm pushing a change that drops mention of the legacy option entirely, since it's not used. Let me know if there's anything else.

Looks like the windows build passed with the one test restored, so we'll leave that change in the PR.

Looks good to me.

Was looking at using the legacy flag with the existing vswhere query this morning for msvc versions 10.0, 11.0, 12.0, and 14.0. Not exactly a quick change but possible. Not sure worth pursuing for imminent release. If nothing else, wouldn't be issuing as many registry queries.

Looks good to me.

Was looking at using the legacy flag with the existing vswhere query this morning for msvc versions 10.0, 11.0, 12.0, and 14.0. Not exactly a quick change but possible. Not sure worth pursuing for imminent release. If nothing else, wouldn't be issuing as many registry queries.

That'd probably be worth it (for the next release, not the imminent one).
So we could support >=10.0 with only vswhere in a new msvc tool, and just leave the old one for legacy, and that would simplify things?

So we could support >=10.0 with only vswhere in a new msvc tool, and just leave the old one for legacy, and that would simplify things?

I'm not sure how much it simplifies things yet. I am not clear on what exactly new vs legacy means from a source organization perspective and for supported features moving forward. I'm not intentionally being obtuse, I just don't have a clear internal picture of what the desired end goal looks like.

In many ways, versions 2017 and later are more complex than earlier versions. While the older versions can be pruned, I'm not sure what the magnitude of the effects are with regards to code size, complexity, or run-time performance.

In the near term, it might be possible to emulate the effects of pruning versions by adding a "minimum version" for detection and support without actually removing any code.

Detection of installation roots (either via vswhere or the registry) is reasonably straightforward. Versions of 10.0 to 14.0 detected with vswhere would still need to be "classified" (development vs express, etc) as vswhere provides no information other than the vs root which is similar to the registry queries. VS2015 is in general more challenging than other versions if one is interested in validation of arguments.

Vswhere does appear to correctly detect the legacy build tools (14.0) and express versions (10.0-14.0) and does not detect legacy SDK-only installations (a good thing).

The tradeoff between using vswhere vs the registry for 10.0-14.0 might be just be issuing fewer registry queries. The complexity may be largely the same as what is present now.

In any case, I'm happy to work with you both.

So we could support >=10.0 with only vswhere in a new msvc tool, and just leave the old one for legacy, and that would simplify things?

I'm not sure how much it simplifies things yet. I am not clear on what exactly new vs legacy means from a source organization perspective and for supported features moving forward. I'm not intentionally being obtuse, I just don't have a clear internal picture of what the desired end goal looks like.

In many ways, versions 2017 and later are more complex than earlier versions. While the older versions can be pruned, I'm not sure what the magnitude of the effects are with regards to code size, complexity, or run-time performance.

In the near term, it might be possible to emulate the effects of pruning versions by adding a "minimum version" for detection and support without actually removing any code.

Detection of installation roots (either via vswhere or the registry) is reasonably straightforward. Versions of 10.0 to 14.0 detected with vswhere would still need to be "classified" (development vs express, etc) as vswhere provides no information other than the vs root which is similar to the registry queries. VS2015 is in general more challenging than other versions if one is interested in validation of arguments.

Vswhere does appear to correctly detect the legacy build tools (14.0) and express versions (10.0-14.0) and does not detect legacy SDK-only installations (a good thing).

The tradeoff between using vswhere vs the registry for 10.0-14.0 might be just be issuing fewer registry queries. The complexity may be largely the same as what is present now.

In any case, I'm happy to work with you both.

Moving discussion to: #4565