I would like to take an opportunity to document some of the behavior of the
toolset version and some of the terminology used as a basis for further
discussion. Also, I believe that the consistency gap is for a narrow
subset of the possible extended specifications.
Toolset: 14.2[X[.YYYYY]], 14.1[X[.YYYYY]], 14.0
Product: 14.2 (MSVC 2019), 14.1 (MSVC 2017), 14.0 (MSVC 2015)
Component: Enterprise (Ent), Professional (Pro), Community (Com),
BuildTools (BT), WDExpress (Exp)
The component ids used are from Microsoft’s documentation of the workloads
and component ids for 2019 and 2017. The abbreviations are similar to that
used for Express. The component ids are returned in vswhere queries. The
component id tables are shown at the end of the document along with the
reference links.
Temporarily suspend the distaste of the extended syntax (there is a method
to the madness). The extended syntax for the MSVC_VERSION is not as
“free-wheeling” as it might appear and “binds” to specific products in a
number of cases. This is by design.
The point of departure is the semantics for specifications that do not bind
to a specific product. This may be able to be resolved using a
command-line option to SCons and/or another argument in the environment.
I believe Bill may have suggested this earlier. A command-line argument
would have significant utility as it would not require changes to build
scripts.
The regular expression that parses/validates the format is shown below.
Currently, any specification that includes a component is automatically
bound to a specific product.
The following table includes examples from the original email and
illustrates how the specification is resolved initially by default:
User
Internal (Resolved Once Upon Entry)
MSVC_VERSION
MSVC_VERSION
Toolset
Product
Comp
14.1
14.1+
14.1
*
*
14.16
14.1+
14.16
*
*
14.16.27
14.1+
14.16.27
*
*
14.16.27023
14.1+
14.16.27023
*
*
14.26Ent
14.2
14.26
14.2
Ent
14.2Pro
14.2
14.2
14.2
Pro
14.26.27Com
14.2
14.26.27
14.2
Com
14.2BT
14.2
14.2
14.2
BT
14.1Exp
14.1
14.1
14.1
Exp
14.0 -> 14.2
14.2
14.0
14.2
*
14.1 -> 14.2BT
14.2
14.1
14.2
BT
14.16 -> 14.2Com
14.2
14.16
14.2
Com
+ Indicates that the preferred product version but may be “promoted” to a
later version. This is the undesirable behavior.
* Indicates that the product or component is not bound to a specific
product and/or component.
The toolset is a “proper” prefix (i.e., “startswith”).
Again, I believe this may have been suggested earlier: the default behavior
could be changed to “bind” to the native product for the toolset (i.e., the
“Product” for the first four rows in the table above would be “14.1”). In
this case, the only ambiguity in the selection would be which product
“kind” (i.e., component id) is selected which is what happens in the
current msvc detection. The alternative behavior, either via command-line
option and/or additional variable, would be the toolset functionality as
currently implemented.
Issue #3664 succinctly illustrates the differences between the two
behaviors. The two options are shown below in the context of the current
extended toolset version specification:
Assume that no 14.1 products are installed, and the 14.2 Build Tools
edition is installed with the 14.1 toolset.
No promotion
Result
MSVC_VERSION="14.1"
Error – 14.1 Not Found
MSVC_VERSION="14.1->14.2"
14.2 Build Tools
MSVC_VERSION=”14.1->14.2BT”
14.2 Build Tools
Promotion
Result
MSVC_VERSION="14.1"
14.2 Build Tools
MSVC_VERSION="14.1->14.2"
14.2 Build Tools
MSVC_VERSION=”14.1->14.2BT”
14.2 Build Tools
In either case, the issue of using the 14.1 toolset with the 14.2 product
can be resolved with the extended syntax and without product ambiguity
(i.e., the last row). The second specification would leave open the kind
(i.e., component) of product selected.
>From an end-user perspective, adding “->14.2” is easier than going via the
custom batch file route or even adding an additional variable. A
command-line option to enable the extended behavior may be preferable
especially if using a batch file to launch SCons.
The point of departure is simply what should the default behavior be when a
specification is not bound to a specific product and what should the
mechanism be to enable the other behavior.
The extended MSVC_VERSION format regular expression and Microsoft component
ids for 2019 and 2017 are shown below.
Regards,
Joe
*Extended MSVC_VERSION format:*
*# Regular Expression to validate/parse MSVC_VERSION*
*#*
*# named groups:*
*# version: _VCVER version or specific version*
*# vcver: _VCVER version or None*
*# specific: specific version or None*
*# product: _VCVER version or None*
*# suffix: product type suffix or None*
_MSVC_EXTENDED_VERSION_RE = re.compile("""
*# anchor at start of string*
^
*# version number*
(?P<version>
*# _VCVER version: 14.2*
(?P<vcver> \d{1,2} \. \d{1} )
|
*# toolset version: 14.16, 14.16.27023*
(?P<specific> \d{1,2} \. \d{2} (?: \. \d{1,5} )* )
)
*# optional product: '->' 14.2*
(?:
*# optional whitespace*
\s*
*# right assignment literal '->'*
[-][>]
*# optional whitespace*
\s*
*# _VCVER version: 14.2*
(?P<product> \d{1,2} \. \d{1} )
)*
*# optional whitespace*
\s*
*# optional product type: Ent, Pro, Com, Exp, BT, etc.*
(?P<suffix> [A-Z][A-Za-z]+)*
*# anchor at end of string*
$
""", re.VERBOSE)
*Component IDs – 2019 and 2017 (vswhere query components):*
https://docs.microsoft.com/en-us/visualstudio/install/workload-and-component-ids?view=vs-2019
*Edition*
*ID*
Visual Studio Enterprise 2019
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-enterprise?view=vs-2019>
Microsoft.VisualStudio.Product.Enterprise
Visual Studio Professional 2019
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-professional?view=vs-2019>
Microsoft.VisualStudio.Product.Professional
Visual Studio Community 2019
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-community?view=vs-2019>
Microsoft.VisualStudio.Product.Community
Visual Studio Team Explorer 2019
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-team-explorer?view=vs-2019>
Microsoft.VisualStudio.Product.TeamExplorer
Visual Studio Build Tools 2019
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-build-tools?view=vs-2019>
Microsoft.VisualStudio.Product.BuildTools
Visual Studio Test Agent 2019
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-test-agent?view=vs-2019>
Microsoft.VisualStudio.Product.TestAgent
Visual Studio Load Test Controller 2019
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-test-controller?view=vs-2019>
Microsoft.VisualStudio.Product.TestController
https://docs.microsoft.com/en-us/visualstudio/install/workload-and-component-ids?view=vs-2017
*Edition*
*ID*
Visual Studio Enterprise 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-enterprise?view=vs-2017>
Microsoft.VisualStudio.Product.Enterprise
Visual Studio Professional 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-professional?view=vs-2017>
Microsoft.VisualStudio.Product.Professional
Visual Studio Community 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-community?view=vs-2017>
Microsoft.VisualStudio.Product.Community
Visual Studio Team Explorer 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-team-explorer?view=vs-2017>
Microsoft.VisualStudio.Product.TeamExplorer
Visual Studio Desktop Express 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-express?view=vs-2017>
Microsoft.VisualStudio.Product.WDExpress
Visual Studio Build Tools 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-build-tools?view=vs-2017>
Microsoft.VisualStudio.Product.BuildTools
Visual Studio Test Agent 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-test-agent?view=vs-2017>
Microsoft.VisualStudio.Product.TestAgent
Visual Studio Test Controller 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-test-controller?view=vs-2017>
Microsoft.VisualStudio.Product.TestController
Visual Studio Test Professional 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-test-professional?view=vs-2017>
Microsoft.VisualStudio.Product.TestProfessional
Visual Studio Feedback Client 2017
<https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-feedback-client?view=vs-2017>
Microsoft.VisualStudio.Product.FeedbackClient
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
