Refactor vswhere executable support and detection.

vswhere changes:
* Split the current vswhere paths list into two lists:
  * the visual studio installer locations,
  * the package manager locations.
* Add additional user vswhere priority groups:
  * before the vs installer locations [high priority],
  * after the vs installer locations [default priority], and
  * after the package manager locations [low priority].
* Adjust tests for vswhere path list changes accordingly.
* Add vswhere location functions to:
  * register user vswhere executable paths by priority,
  * get the currently configured vswhere executable location,
  * freeze the vswhere executable location used for detection.
* Assign the environment VSWHERE construction variable in Tool/MSCommon/vc.py.
* Remove the assignment of the environment VSWHERE construction variable in Tool/msvc.py
* Update the test suite function signature for finding the msvc product directory with vswhere.
* Freeze the vswhere executable in the following functions before the cache is evaluated which will raise an exception if the vswhere executable has changed since the initial detection (if necessary):
  * MSCommon.vc.get_installed_visual_studios,
  * MSCommon.vc.find_vc_pdir,
  * MSCommon.vc.msvc_setup_env,
  * MSCommon.vs.get_installed_visual_studios

Author: jcbrill

CHANGES.txt

@@ -85,13 +85,16 @@ RELEASE  VERSION/DATE TO BE FILLED IN LATER
       of the results from all vswhere executables).  There is a single invocation for
       each vswhere executable that processes the output for all installations.  Prior
       implementations called the vswhere executable for each supported msvc version.
-    - Previously, the installed vcs and visual studios lists were constructed once and
-      cached at runtime.  If a vswhere executable was specified via the construction
-      variable VSWHERE and found additional msvc installations, the new installations
-      were not reflected in the installed vcs and visual studios lists. Now, when a
-      user-specified vswhere executable finds new msvc installations, internal runtime
-      caches are cleared and the installed vcs and visual studios lists are reconstructed
-      on their next retrieval.
+    - The vswhere executable is frozen upon initial detection.  Specifying a different
+      vswhere executable via the construction variable VSWHERE after the initial
+      detection now results in an exception.  Multiple bugs in the implementation of
+      specifying a vswhere executable via the construction variable VSWHERE have been
+      fixed.  Previously, when a user specified vswhere executable detects new msvc
+      installations after the initial detection, the internal msvc installation cache
+      and the default msvc version based on the initial detection are no longer valid.
+      For example, when no vswhere executable is found for the initial detection
+      and then later an environment is constructed with a user specified vswhere
+      executable that detects new msvc installations.
 
   From Thaddeus Crews:
     - Implemented SCons.Util.sctyping as a safe means of hinting complex types. Currently

RELEASE.txt

@@ -75,13 +75,16 @@ FIXES
   is now selected before a Visual C++ For Python edition. Prior to this change,
   Visual C++ For Python was selected before a full development edition when both
   editions are installed.
-- MSVC: The installed vcs and visual studios lists were constructed and cached
-  during their initial invocations. If a vswhere executable was specified via the
-  construction variable VSWHERE and found additional msvc installations, the new
-  installations were not reflected in the cached installed vcs and visual studios
-  lists. Now, when a user-specified vswhere executable finds new msvc installations,
-  the installed vcs and visual studios lists are cleared and reconstructed on their
-  next retrieval.
+- The vswhere executable is frozen upon initial detection.  Specifying a different
+  vswhere executable via the construction variable VSWHERE after the initial
+  detection now results in an exception.  Multiple bugs in the implementation of
+  specifying a vswhere executable via the construction variable VSWHERE have been
+  fixed.  Previously, when a user specified vswhere executable detects new msvc
+  installations after the initial detection, the internal msvc installation cache
+  and the default msvc version based on the initial detection are no longer valid.
+  For example, when no vswhere executable is found for the initial detection
+  and then later an environment is constructed with a user specified vswhere
+  executable that detects new msvc installations.
 - On Windows platform, when collecting command output (Configure checks),
   make sure decoding of bytes doesn't fail.
 - Documentation indicated that both Pseudo() and env.Pseudo() were usable,

SCons/Tool/MSCommon/MSVC/Util.py

@@ -37,6 +37,15 @@
 
 from . import Config
 
+
+# call _initialize method upon class definition completion
+
+class AutoInitialize:
+    def __init_subclass__(cls, **kwargs):
+        super().__init_subclass__(**kwargs)
+        if hasattr(cls, '_initialize') and callable(getattr(cls, '_initialize', None)):
+            cls._initialize()
+
 # path utilities
 
 # windows drive specification (e.g., 'C:')

SCons/Tool/MSCommon/__init__.py

@@ -45,6 +45,9 @@
     msvc_toolset_versions,
     msvc_toolset_versions_spectre,
     msvc_query_version_toolset,
+    vswhere_register_executable,
+    vswhere_get_executable,
+    vswhere_freeze_executable,
 )
 
 from SCons.Tool.MSCommon.vs import (  # noqa: F401
@@ -78,7 +81,9 @@
     MSVCUnsupportedHostArch,
     MSVCUnsupportedTargetArch,
     MSVCScriptNotFound,
+    MSVCUseScriptError,
     MSVCUseSettingsError,
+    VSWhereUserError,
 )
 
 from .MSVC.Util import (  # noqa: F401