MSVC 2017+ Toolset Support
Joseph Brill <[email protected]> Sun, 9 Aug 2020 17:51:04 -0400
| Newsgroups | gmane.comp.programming.tools.scons.devel |
|---|---|
| Message-ID | <CAJLrGP2d-BB=z3JTY6ha=bohdX-3SvWAudHPpVTq01HBMp=oJA@mail.gmail.com> |
--===============5869520031239928912==
Content-Type: multipart/alternative; boundary="00000000000052363605ac78d44e"
--00000000000052363605ac78d44e
Content-Type: text/plain; charset="UTF-8"
This email is an attempt to focus the discussion concerning support for
MSVC toolsets moving forward in a rational, dispassionate discourse.
I am advocating a minor shift in orientation or "world view" for MSVC 2017
and later: the semantic transition from thinking of the msvc version as a
product to thinking of the msvc version as a toolset. This actually makes
the implementation of toolset support easier.
There is a working version of the support for toolsets at varying levels of
precision that can be enabled and disabled. The intent is that a
command-line switch could be added to enable the toolset specific
capabilities. By default, the toolset specific capabilities would be
disabled in which case the code behaves exactly like the current master.
This would allow field testing and evaluation of the functionality in other
environments and to easily test the differences between the current master
and the toolset functionality. The functional aspects are feature
complete. The working version is a product of more than one man-month of
full-time development activity and the result of the third iteration of
implementation strategy.
Existing PR #3717 was closed and the branch renamed due in part to make it
easier to identify and maintain for myself as I fear that I might be time
limited in the near term and due in part to the existing discussion
unraveling fairly quickly with dim prospects of inclusion moving
forward. Despite
being closed, I recommend viewing the "documentation" (the PR text and the
first comment) and the vc.py code difference in PR #3717. At any time the
PR request can be reopened. I would need a git guru to walk me through
associating the new branch name with the "old" PR.
The implementation knocks an item or two off the internal vc.py TODO list
such as a single vswhere query and processing the json results for all
known installations. Ranked toolset lists are constructed by host/target.
The ranking takes into account the toolset version and product type. A
single toolset instance may be a member of multiple toolset lists.
Expensive lookups are "runtime memoized/cached" so that they are only
computed once. While there is a fair amount of initialization, the
processing burden is based on the number of products installed and the
number of toolsets for each product. Typical environments likely have a
single product installation with a spartan number of different toolsets
installed. There is nothing particularly "clever" done in the
implementation and should not be a maintenance burden. The bulk of the
toolset support implementation follows the code in the existing master
(i.e., the bottom of the file). The modifications to support toolsets
weighs in at approximately 1400 lines of code.
Prior to MSVS 2017, there was a direct 1:1 mapping between the msvc
*product* and the msvc *toolset*. The toolset might be upgraded in an
update or service pack but there was no way to select a specific toolset as
side-by-side installations were not supported. That changed with the
release of MSVC 2017 which allows multiple side-by-side toolset
installations by target. MSVC 2017 and later, can be viewed as
*toolset* oriented
(i.e., a MSVC 2019 installation can be viewed as a container for 14.1X,
14.2X, and transparently the 14.0 toolsets). Moving forward, I believe
that it will be advantageous to change from a *product* orientation to a
*toolset* orientation. This change is only for the 2017 and later
installations and currently really only affects 2017.
With MSVC 2017 and MSVC 2019, an SCons version request of "14.1" or "14.2",
respectively, *is a toolset request* that cannot be specified at a finer
granularity. The current msvc behavior uses the *default toolset* which is
generally the newest installed *toolset* version when the "--vcvars_ver"
argument is not specified for the vcvars batch file.
For example, a version request of "14.1" is likely to use the "14.16.27023"
toolset when MSVC 2017 is installed. Effectively, the *product request* is
a *toolset request* identical to "find the newest toolset version installed
that starts with '14.1'". However, "14.2" (MSVC 2019) will return a
*toolset* based on the latest update which likely varies across users and
computers. Currently, a request for "14.1" will fail if MSVC 2019 is
installed with the 14.1 toolset. With a toolset orientation, a 14.1
toolset request would be satisfied first by the native product (i.e., MSVC
2017) for the toolset and then by the latest product that contains the user
specified toolset for a given host/target combination. This two-stage
query, if necessary, is implemented in the working toolset oriented version.
Currently, the actual toolset versions used for 2017 and 2019 are based on
end-user's installation options and frequency of updates. While two
different users may be using the same *product* (e.g., 2019) they may not
be using the same *toolset*. Similarly, the installed toolset version is
not necessarily the same for all host/target combinations within a given
product installation. The current implementation uses a default
*toolset* within
a product across different users and environments, which may not be the
same for all instances, but currently cannot use a *toolset* across product
installations.
There may be many reasons (e.g., enterprise and/or customer requirements)
that build scripts are tied to a specific toolset. If a build depends on
the 14.1 *toolset* it hardly seems as important in which *product* container
it is installed from an end-user's perspective given the two-stage
selection rule described earlier. Given the same toolset, the produced
binaries should be binary compatible independent of the product
installation. The same issue will arise when the next MSVC *product* is
released and end-users desire to use the 14.2X *toolset* combination in the
new product container.
At present, the shift in toolset orientation would only affect user's that
desire the 14.1 toolset and do not have MSVC 2017 installed. In this case,
the only other product that can be used is MSVC 2019. This isolates the
effects of changes to a single version of MSVC.
This could have a tangible side-effect of making build scripts more
portable: the build scripts can be tied to a toolset rather than a
toolset/product combination. Although if it is desired to specify the
toolset/product combination that is supported as well.
The MSVC_VERSION format was expanded to allow:
- specifying an individual toolset at varying degrees of precision:
- "14.1"
- "14.16"
- "14.16.27"
- "14.16.27023"
- specifying individual product types (attached to a specific toolset or a
product):
- Enterprise: "14.26Ent"
- Professional: "14.2Pro"
- Community: "14.26.27Com"
- Build Tools: "14.2BT"
- Express: "14.1Exp"
- a right assignment operator ("->") that maps a specific toolset to a
defined product version with an optional product type:
- "14.0->14.2" use the the 14.0 toolset via a 2019 installation
- "14.1->14.2BT" use the 14.1 toolset via a 2019 Build Tools
installation
- "14.1->14.2Com" use the 14.1 toolset via a 2019 Community
installation
The translation of the extended version specification to a supplementary
internal data structure is done in exactly one source code location:
msvc_setup_env. All existing code continues to operate on the "NN.M"
format for MSVC_VERSION as before. Existing msvc/msvs test suites pass all
tests. However, issues with the extended format being used prior to entry
in vc.py script have yet to be identified, if any. The working version is
completely self-contained in the vc.py script.
Without a product qualifier (e.g., "BT"), there is a *subtle but
significant* change semantically: the product selected will be the
newest/latest toolset that matches the user specification within installed
toolsets for a given (host,target) combination. Effectively, without a
product qualifier, any product type could be returned based on the
installed toolsets. This only affects multiple installations of the same
product version (e.g., 14.1 and 14.Exp and/or 14.2Com and 14.2BT). For end
users that only have one product installed, there is no reason to specify a
product type.
This means that a user does not need to specify "14.1Exp" explicitly if
there is a single 14.1 product installation. On the flip side, it also
means that "14.1Exp" may be returned for a "14.1" request. In local
testing, "14.1Exp" was returned for an "arm" target. In the local
installations of 14.1 Community and 14.1 Express, the "newest" toolset for
an arm target was in the 14.1 Express installation as it was installed the
most recently. With a product qualifier, a specific product version and
type is selected.
To be clear, I do not need any fixes, enhancements, and am not reporting
any bugs. The toolset version development was done in the spirit of
contributing to software that I have used since 2.X. I had a development
window to contribute to the windows/msvc support and in process address two
of the outstanding msvc items on the issues list. I was motivated by both
the post in the scons users mailing list shown below and issue #3664. As I
am familiar with the msvc detection code, my initial thoughts were "how
hard could it be?"
Regards,
Joe
https://pairlist4.pair.net/pipermail/scons-users/2020-June/008216.html
>* The problem is scons don't find any 14.1(2017) installation, he only find
*>* 14.2(2019).
*> >* Is there something I could do to tell scons that 141 is
installed somewhere
*>* in vs2019 installation?
*
at the moment, no... it's a work in progress.
See https://github.com/SCons/scons/issues/3664
There wasn't really a "Windows native" person involved in the most
recent times, so we didn't end up understanding about the model of
multiple versions under one VS install - and in particular that people
would want to get 14.1 from VS2019 rather than keep VS2017 installed.
For the most recent VS installs, vswhere is used to detect them, but we
find only the "default version" under each product vswhere reports, so
14.2.latest for 2019, 14.1 for 2017.
--00000000000052363605ac78d44e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);fon=
t-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,He=
lvetica,Arial,sans-serif,"Segoe UI Symbol","Apple Color Emoj=
i";font-size:17.9776px"><span style=3D"font-size:17.9776px">This email=
is an attempt to focus the discussion concerning=C2=A0support for MSVC too=
lsets moving forward in a rational, dispassionate discourse.</span></p><p s=
tyle=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-apple-syste=
m,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-se=
rif,"Segoe UI Symbol","Apple Color Emoji";font-size:17.=
9776px">I am advocating a minor shift in orientation or "world view&qu=
ot; for MSVC 2017 and later: the semantic transition from thinking of the m=
svc version as a product to thinking of the msvc version as a toolset.=C2=
=A0 This actually makes the implementation of toolset support easier.</p><p=
style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-apple-sys=
tem,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-=
serif,"Segoe UI Symbol","Apple Color Emoji";font-size:1=
7.9776px"><span style=3D"font-size:17.9776px">There is a working version of=
the support for </span>toolsets<span style=3D"font-size:17.9776px"> at var=
ying levels of precision that can be enabled and disabled.=C2=A0 The intent=
is that a command-line switch could be added to enable the toolset specifi=
c capabilities.=C2=A0 By default, the toolset specific capabilities would b=
e disabled in which case the code behaves exactly like </span>the<span styl=
e=3D"font-size:17.9776px">=C2=A0current master.=C2=A0 This would allow fiel=
d testing and evaluation of the functionality in other environments and to =
easily test the=C2=A0differences between the current master and the toolset=
functionality.=C2=A0 The functional aspects are feature complete.=C2=A0 Th=
e working version is a product of more than one man-month of full-time deve=
lopment activity and the result of the third iteration of implementation st=
rategy.</span></p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);fo=
nt-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,H=
elvetica,Arial,sans-serif,"Segoe UI Symbol","Apple Color Emo=
ji";font-size:17.9776px"><span style=3D"font-size:17.9776px">Existing =
PR #3717 was closed and the branch renamed due in part to make it easier to=
identify and maintain for myself as I fear that I might be time limited in=
the near term and due in part to the existing discussion unraveling fairly=
quickly with dim=C2=A0prospects of inclusion moving forward.=C2=A0=C2=A0</=
span><span style=3D"font-size:17.9776px">Despite being closed, I recommend =
viewing the "documentation" (the PR text and the first comment) a=
nd the vc.py code difference in PR #3717.=C2=A0 At any time the PR request =
can be reopened.=C2=A0 I would need a git guru to walk me through associati=
ng the new branch name with the "old" PR.</span></p><p style=3D"m=
argin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-apple-system,BlinkMa=
cSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-serif,"=
;Segoe UI Symbol","Apple Color Emoji";font-size:17.9776px"><=
span style=3D"font-size:17.9776px">The implementation knocks an item or two=
off the internal vc.py TODO list such as a single vswhere=C2=A0query and p=
rocessing the json results for all known installations.=C2=A0 Ranked toolse=
t lists are constructed by host/target.=C2=A0 The ranking takes into accoun=
t the toolset version and product type.=C2=A0 A single toolset instance may=
be a member of multiple toolset lists.=C2=A0 Expensive lookups are "r=
untime memoized/cached" so that they are only computed once.=C2=A0 Whi=
le there is a fair amount of initialization, the processing burden is based=
on the number of products installed and the number of toolsets for each pr=
oduct.=C2=A0 Typical environments likely have a single product installation=
with a spartan number of different toolsets installed. There is nothing pa=
rticularly "clever" done in the implementation and should not be =
a maintenance burden.=C2=A0 The bulk of the toolset support implementation =
follows the code in the existing master (i.e., the bottom of the file).=C2=
=A0 The modifications to support toolsets weighs in at approximately=C2=A01=
400 lines of code.</span><br></p><p style=3D"margin:0.5rem 0px 1rem;color:r=
gb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI&qu=
ot;,Helvetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","=
Apple Color Emoji";font-size:17.9776px">Prior to MSVS 2017, there was =
a direct 1:1 mapping between the msvc=C2=A0<em>product</em>=C2=A0and the ms=
vc=C2=A0<em>toolset</em>. The toolset might be upgraded in an update or ser=
vice pack but there was no way to select a specific toolset as side-by-side=
installations were not supported.=C2=A0 That changed with the release of M=
SVC 2017 which allows multiple side-by-side toolset installations by target=
.=C2=A0=C2=A0<span style=3D"font-size:17.9776px">MSVC 2017 and later, can b=
e viewed as=C2=A0</span><span style=3D"font-size:17.9776px"><em>toolset</em=
></span><span style=3D"font-size:17.9776px">=C2=A0oriented (i.e., a MSVC 20=
19 installation can be viewed as a container for 14.1X, 14.2X, and transpar=
ently the 14.0 toolsets).=C2=A0 Moving forward, I believe that it will be a=
dvantageous to change from a=C2=A0</span><span style=3D"font-size:17.9776px=
"><em style=3D"">product</em></span><span style=3D"font-size:17.9776px">=C2=
=A0orientation to a <i>toolset</i> orientation.=C2=A0 This change is only f=
or the 2017 and later installations and currently really only affects 2017.=
</span></p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-fami=
ly:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvetic=
a,Arial,sans-serif,"Segoe UI Symbol","Apple Color Emoji"=
;;font-size:17.9776px"></p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,=
51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",He=
lvetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","Apple =
Color Emoji";font-size:17.9776px">With MSVC 2017 and MSVC 2019, an SCo=
ns version request of "14.1" or "14.2", respectively,=
=C2=A0<em style=3D"">is a toolset request</em>=C2=A0that cannot be specifie=
d at a finer granularity. The current msvc behavior uses the=C2=A0<em>defau=
lt toolset</em>=C2=A0which is generally the newest installed=C2=A0<em>tools=
et</em>=C2=A0version when the "--vcvars_ver" argument is not spec=
ified for the vcvars batch file.</p><p style=3D"margin:0.5rem 0px 1rem;colo=
r:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI=
",Helvetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol",&qu=
ot;Apple Color Emoji";font-size:17.9776px">For example, a version requ=
est of "14.1" is likely to use the "14.16.27023" toolse=
t when MSVC 2017 is installed. Effectively, the=C2=A0<em>product request</e=
m>=C2=A0is a=C2=A0<em>toolset request</em>=C2=A0identical to "find the=
newest toolset version installed that starts with '14.1'". Ho=
wever, "14.2" (MSVC 2019) will return a=C2=A0<em>toolset</em>=C2=
=A0based on the latest update which likely varies across users and computer=
s.=C2=A0 Currently, a request for "14.1" will fail if MSVC 2019 i=
s installed with the 14.1 toolset.=C2=A0 With a toolset orientation, a 14.1=
toolset request would be satisfied first by the native product (i.e., MSVC=
2017) for the toolset and then by the latest product that contains the use=
r specified toolset for a given host/target combination.=C2=A0 This two-sta=
ge query, if necessary, is implemented in the working toolset oriented vers=
ion.</p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:=
-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvetica,A=
rial,sans-serif,"Segoe UI Symbol","Apple Color Emoji";f=
ont-size:17.9776px">Currently, the actual toolset versions used for 2017 an=
d 2019 are based on end-user's installation options and frequency of up=
dates. While two different users may be using the same=C2=A0<em>product</em=
>=C2=A0(e.g., 2019) they may not be using the same=C2=A0<em>toolset</em>. S=
imilarly, the installed toolset version is not necessarily the same for all=
host/target combinations within a given product installation.=C2=A0 T<span=
style=3D"font-size:17.9776px">he current implementation uses a default=C2=
=A0</span><em style=3D"font-size:17.9776px">toolset</em><span style=3D"font=
-size:17.9776px">=C2=A0within a product across different users and environm=
ents, which may not be the same for all instances, but currently cannot use=
a=C2=A0</span><em style=3D"font-size:17.9776px">toolset</em><span style=3D=
"font-size:17.9776px">=C2=A0across product installations.</span></p><p styl=
e=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-apple-system,B=
linkMacSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-serif=
,"Segoe UI Symbol","Apple Color Emoji";font-size:17.977=
6px"><span style=3D"font-size:17.9776px">There may be many reasons (e.g., e=
nterprise and/or customer requirements) that build scripts are tied to a sp=
ecific toolset.=C2=A0 If a build depends on the 14.1=C2=A0</span><em style=
=3D"font-size:17.9776px">toolset</em><span style=3D"font-size:17.9776px">=
=C2=A0it hardly seems as important in which=C2=A0</span><em style=3D"font-s=
ize:17.9776px">product</em><span style=3D"font-size:17.9776px">=C2=A0contai=
ner it is installed from an end-user's perspective given the two-stage =
selection rule described=C2=A0earlier.=C2=A0 Given the same=C2=A0toolset, t=
he produced binaries should be binary compatible independent of the product=
installation.=C2=A0 The same issue will arise when the next MSVC=C2=A0</sp=
an><em style=3D"font-size:17.9776px">product</em><span style=3D"font-size:1=
7.9776px">=C2=A0is released and end-users desire to use the 14.2X=C2=A0</sp=
an><em style=3D"font-size:17.9776px">toolset</em><span style=3D"font-size:1=
7.9776px">=C2=A0combination in the new product container.</span><br></p><p =
style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-apple-syst=
em,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-s=
erif,"Segoe UI Symbol","Apple Color Emoji";font-size:17=
.9776px">At present, the shift in toolset orientation would only affect use=
r's that desire the 14.1 toolset and do not have MSVC 2017 installed.=
=C2=A0 In this case, the only other product that can be used is MSVC 2019.=
=C2=A0 This isolates the effects of changes to a single version of MSVC.</p=
><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-apple-=
system,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,sa=
ns-serif,"Segoe UI Symbol","Apple Color Emoji";font-siz=
e:17.9776px">This could have a tangible side-effect of making build scripts=
more portable: the build scripts can be tied to a toolset rather than a to=
olset/product combination.=C2=A0 Although if it is desired to specify the t=
oolset/product combination that is supported as well.</p><p style=3D"margin=
:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSyst=
emFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-serif,"Sego=
e UI Symbol","Apple Color Emoji";font-size:17.9776px"><span =
style=3D"font-size:17.9776px">The MSVC_VERSION format was expanded to allow=
:</span><br></p><ul style=3D"margin:1.1em 0px;color:rgb(51,51,51);font-fami=
ly:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvetic=
a,Arial,sans-serif,"Segoe UI Symbol","Apple Color Emoji"=
;;font-size:17.9776px"><li style=3D"margin:0.6em 0.2em 0.6em 1em">specifyin=
g an individual toolset at varying degrees of precision:<ul style=3D"margin=
:1.1em 0px"><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-style:square">&q=
uot;14.1"</li><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-style:squ=
are">"14.16"</li><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-s=
tyle:square">"14.16.27"</li><li style=3D"margin:0.6em 0.2em 0.6em=
1em;list-style:square">"14.16.27023"</li></ul></li><li style=3D"=
margin:0.6em 0.2em 0.6em 1em">specifying individual product types (attached=
to a specific toolset=C2=A0<span style=3D"font-weight:600">or</span>=C2=A0=
a product):<ul style=3D"margin:1.1em 0px"><li style=3D"margin:0.6em 0.2em 0=
.6em 1em;list-style:square">Enterprise: "14.26Ent"</li><li style=
=3D"margin:0.6em 0.2em 0.6em 1em;list-style:square">Professional: "14.=
2Pro"</li><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-style:square"=
>Community: "14.26.27Com"</li><li style=3D"margin:0.6em 0.2em 0.6=
em 1em;list-style:square">Build Tools: "14.2BT"</li><li style=3D"=
margin:0.6em 0.2em 0.6em 1em;list-style:square">Express: "14.1Exp"=
;</li></ul></li><li style=3D"margin:0.6em 0.2em 0.6em 1em">a right assignme=
nt operator ("->") that maps a specific toolset to a defined p=
roduct version with an optional product type:<ul style=3D"margin:1.1em 0px"=
><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-style:square">"14.0-&g=
t;14.2" use the the 14.0 toolset via a 2019 installation</li><li style=
=3D"margin:0.6em 0.2em 0.6em 1em;list-style:square">"14.1->14.2BT&q=
uot; use the 14.1 toolset via a 2019 Build Tools installation</li><li style=
=3D"margin:0.6em 0.2em 0.6em 1em;list-style:square">"14.1->14.2Com&=
quot; use the 14.1 toolset via a 2019 Community installation</li></ul></li>=
</ul><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-size:17.97=
76px;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helv=
etica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","Apple Co=
lor Emoji""><span style=3D"font-size:17.9776px">The translation of the=
extended version specification to a supplementary internal data structure =
is done in exactly one source code location: msvc_setup_env</span><span sty=
le=3D"font-size:17.9776px">.=C2=A0 All existing code continues to operate o=
n the "NN.M" format for MSVC_VERSION as before.=C2=A0 Existing ms=
vc/msvs test suites pass all tests.=C2=A0 However, issues with the extended=
format being used prior to entry in vc.py=C2=A0script have yet to be ident=
ified, if any.=C2=A0 The working version is completely self-contained in th=
e vc.py script.</span></p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,5=
1,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Hel=
vetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","Apple C=
olor Emoji";font-size:17.9776px">Without a product qualifier (e.g., &q=
uot;BT"), there is a=C2=A0<em>subtle but significant</em>=C2=A0change =
semantically: the product selected will be the newest/latest toolset that m=
atches the user specification within installed toolsets for a given (host,t=
arget) combination. Effectively, without a product qualifier, any product t=
ype could be returned based on the installed toolsets. This only affects mu=
ltiple installations of the same product version (e.g., 14.1 and 14.Exp and=
/or 14.2Com and 14.2BT).=C2=A0 For end users that only have one product ins=
talled, there is no reason to specify a product type.</p><p style=3D"margin=
:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSyst=
emFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-serif,"Sego=
e UI Symbol","Apple Color Emoji";font-size:17.9776px">This m=
eans that a user does not need to specify "14.1Exp" explicitly if=
there is a single 14.1 product installation. On the flip side, it also mea=
ns that "14.1Exp" may be returned for a "14.1" request.=
In local testing, "14.1Exp" was returned for an "arm" =
target. In the local installations of 14.1 Community and 14.1 Express, the =
"newest" toolset for an arm target was in the 14.1 Express instal=
lation as it was installed the most recently.=C2=A0=C2=A0<span style=3D"fon=
t-size:17.9776px">With a product qualifier, a specific product version and =
type is selected.</span></p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51=
,51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",H=
elvetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","Apple=
Color Emoji";font-size:17.9776px"><span style=3D"font-size:17.9776px"=
>To be clear, I do not need any fixes, enhancements, and am not reporting a=
ny bugs.=C2=A0 The toolset version development was done in the spirit of co=
ntributing to software that I have used since 2.X.=C2=A0 I had a developmen=
t window to contribute to the windows/msvc support and in process address t=
wo of the outstanding msvc items on the issues list.=C2=A0 I</span><span st=
yle=3D"font-size:17.9776px">=C2=A0was motivated by both the post in the sco=
ns users mailing list shown below and issue #3664.=C2=A0 As I am familiar w=
ith the msvc detection code, my initial thoughts were "how hard could =
it be?"</span></p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,5=
1);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvet=
ica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","Apple Colo=
r Emoji";font-size:17.9776px"><span style=3D"font-size:17.9776px">Rega=
rds,</span></p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-=
family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Helv=
etica,Arial,sans-serif,"Segoe UI Symbol","Apple Color Emoji&=
quot;;font-size:17.9776px">Joe</p><p style=3D"margin:0.5rem 0px 1rem;color:=
rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI&q=
uot;,Helvetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","=
;Apple Color Emoji";font-size:17.9776px"><a href=3D"https://pairlist4.=
pair.net/pipermail/scons-users/2020-June/008216.html">https://pairlist4.pai=
r.net/pipermail/scons-users/2020-June/008216.html</a>=C2=A0=C2=A0<br></p><p=
re style=3D"white-space:pre-wrap;color:rgb(0,0,0)">><i> The problem is s=
cons don't find any 14.1(2017) installation, he only find
</i>><i> 14.2(2019).
</i>><i>=20
</i>><i> Is there something I could do to tell scons that 141 is install=
ed somewhere
</i>><i> in vs2019 installation?
</i>
at the moment, no... it's a work in progress.
See <a href=3D"https://github.com/SCons/scons/issues/3664">https://github.c=
om/SCons/scons/issues/3664</a>
There wasn't really a "Windows native" person involved in the=
most
recent times, so we didn't end up understanding about the model of
multiple versions under one VS install - and in particular that people
would want to get 14.1 from VS2019 rather than keep VS2017 installed.
For the most recent VS installs, vswhere is used to detect them, but we
find only the "default version" under each product vswhere report=
s, so
14.2.latest for 2019, 14.1 for 2017.</pre></div>
--00000000000052363605ac78d44e--
--===============5869520031239928912==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
--===============5869520031239928912==--