Re: MSVC 2017+ Toolset Support
Joseph Brill <[email protected]> Mon, 10 Aug 2020 20:03:16 -0400
| Newsgroups | gmane.comp.programming.tools.scons.devel |
|---|---|
| Message-ID | <CAJLrGP0Q9XEHh6dKTT6Huto9V1uixFd_5Y+sqjBM6GYTtb3Ecw@mail.gmail.com> |
--===============8582787293138903647== Content-Type: multipart/alternative; boundary="000000000000d9062305ac8ecac2" --000000000000d9062305ac8ecac2 Content-Type: text/plain; charset="UTF-8" > "Can I end up with 14.1 installed in both a MSVC2017 and MSVC2019 install (and of course also all the flavors of MSVC, build tools, express, community, enterprise), for a possible total of 8 separate installs? (or some smaller non singular number?)" Yes. I believe the number is 9 separate product installations for 2017 (build tools, express, community, professional, and enterprise) and 2109 (build tools, community, professional, and enterprise). I don't have access to professional or enterprise versions and a I believe the installer for 2017 build tools is rarer than hen's teeth (although it may be available via Chocolatey). As far as I know, there is not an express version of 2019. Locally, I have been using four installations for testing of the 14.1 (14.16) toolsets: 2017 Community, 2017 Express, 2019, Community, and 2019 Build Tools. It is possible to specify the 2015 toolset (14.0) via MSVC 2017 and MSVC 2019 as well. The argument to the vcvars batch file is "14.0". The batch file then effectively finds the 14.0 build tools. The working version uses the registry keys from the msvc batch files to determine if the 14.0 tools are installed. I believe the registry keys used by the msvc batch files.are slightly different that the registry keys that SCons uses for 14.0. I am time limited today and would like to spend some more time thinking about the rest of your email before responding. Implementation note: one advantage of the more complicated syntax is that it is validated with a single fairly straightforward regular expression. The components of interest are captured groups. The string match is done once upon entry. MSVC_VERSION is immediately set to the compatible "14.X" format for the existing code. Except for initial entry, MSVC_VERSION is the currently used format. One reason this was necessary was that the existing code was converting MSVC_VERSION to a floating point number. Even adding the second digit to the MSVC_VERSION (e.g., 14.16) would/could have "broken" the existing code. This was the key to not having to modify a sizable chunk of the existing code. The remaining fields are stored in an internal data structure due to the gap between determining if the tools are installed and actually determining the host/target batch file arguments. > (And yes. I know.. "Foolish consistency is the hobgoblin of little minds", but I think in this case it's not foolish) Emerson. Nice. As you are probably painfully aware by now: "I would have written a shorter letter, but I did not have the time". On Mon, Aug 10, 2020 at 7:23 PM Bill Deegan <bill-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org> wrote: > Can I end up with 14.1 installed in both a MSVC2017 and MSVC2019 install > (and of course also all the flavors of MSVC, build tools, express, > community, enterprise), for a possible total of 8 separate installs? (or > some smaller non singular number?) > > I'm not a fan of the more complicated syntax for MSVC_VERSION and would > rather split out the selection to either separate variables for product, > toolset, and product version and/or a callable which handles selection. > MSVC_VERSION -> sounds like after MSVC2017 defaults to latest installed > toolset unless you set toolset version > MSVC_PRODUCT_VERSION -> Enterprise, Professional, Community, Express, or > not set > MSVC_TOOLSET_VERSION -> This may only apply for MSVC2017 or above (or > could be used if MSVC_VERSION is not set for MSVC < 2017, though that would > likely introduce confusion > > MSVC_SELECTOR -> Callable (too allow more flexibility than static versions > above) > > Otherwise you end up encoding the information in a string and then you > have to decode it. > Seems more complicated than necessary, and we don't have any other > syntaxes embedded in variables thus far. > > I realize you have lots of time invested in your MSVC_VERSION > implementation you've explained, but the goal here is to be consistent with > expected behavior in the face of changed MSVC. > > (And yes. I know.. "Foolish consistency is the hobgoblin of little minds", > but I think in this case it's not foolish) > > Welcome feedback on above. > > > > > On Sun, Aug 9, 2020 at 2:50 PM Joseph Brill <[email protected]> > wrote: > >> 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. >> >> _______________________________________________ >> Scons-dev mailing list >> [email protected] >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > --000000000000d9062305ac8ecac2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div></div><div>> "Can I end up with 14.1 installe= d in both a MSVC2017 and MSVC2019 install (and of course also all=C2=A0 the= flavors of MSVC, build tools, express, community, enterprise), for a possi= ble total of 8 separate installs? (or some smaller non singular number?)&qu= ot;<br></div><div><br></div><div>Yes.=C2=A0 I believe the number is 9 separ= ate product installations for 2017 (build tools, express, community, profes= sional, and enterprise) and 2109 (build tools, community, professional, and= enterprise).=C2=A0 I don't have access to professional or enterprise v= ersions and a I believe the installer for 2017 build tools is rarer than he= n's teeth (although it may be available via Chocolatey).=C2=A0 As far a= s I know, there is not an express version of 2019.=C2=A0 Locally, I have be= en using four installations for testing of the 14.1 (14.16) toolsets: 2017 = Community, 2017 Express, 2019, Community, and 2019 Build Tools.</div><div><= br></div><div>It is possible to specify the 2015 toolset (14.0) via MSVC 20= 17 and MSVC 2019 as well.=C2=A0 The argument to the vcvars batch file is &q= uot;14.0".=C2=A0 The batch file then effectively finds the 14.0 build = tools.=C2=A0 The working version uses the registry keys from the msvc batch= files to determine if the 14.0 tools are installed.=C2=A0 I believe the re= gistry keys used by the msvc batch files.are slightly different that the re= gistry keys that SCons uses for 14.0.</div><div><br></div><div>I am time li= mited today and would like to spend some more=C2=A0time thinking about the = rest of your email before responding.<br></div><div><br></div><div>Implemen= tation note: one advantage of the more complicated syntax is that it is val= idated with a single fairly straightforward regular expression.=C2=A0 The c= omponents of interest are captured groups.=C2=A0 The string match is done o= nce upon entry. MSVC_VERSION is immediately set to the compatible "14.= X" format for the existing code.=C2=A0 Except for initial entry, MSVC_= VERSION is the currently used format.=C2=A0 One reason this was necessary w= as that the existing code was converting MSVC_VERSION to a floating point n= umber.=C2=A0 Even adding the second digit to the MSVC_VERSION (e.g., 14.16)= would/could have "broken" the existing code.=C2=A0 This was the = key to not having to modify a sizable chunk of the existing code.=C2=A0 The= remaining fields are stored in an internal data structure due to the gap b= etween determining if the tools are installed and actually determining the = host/target batch file arguments.</div><div><br></div><div>> (And yes. I= know.. "Foolish consistency is the hobgoblin of little minds", b= ut I think in this case it's not foolish)</div><div><br></div><div>Emer= son.=C2=A0 Nice.=C2=A0 As you are probably painfully aware by now: "I = would have written a shorter letter, but I did not have the time".<br>= </div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Mon, Aug 10, 2020 at 7:23 PM Bill Deegan <<a hre= f=3D"mailto:bill-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org">bill-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org</a>> wr= ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D= "ltr"><div>Can I end up with 14.1 installed in both a MSVC2017 and MSVC2019= install (and of course also all=C2=A0 the flavors of MSVC, build tools, ex= press, community, enterprise), for a possible total of 8 separate installs?= (or some smaller non singular number?)</div><div><br></div><div>I'm no= t a fan of the more complicated syntax for MSVC_VERSION and would rather sp= lit out the selection to either separate variables for product, toolset, an= d product version and/or a callable which handles selection.</div><div>MSVC= _VERSION -> sounds like after MSVC2017 defaults to latest installed tool= set unless you set toolset version<br></div><div>MSVC_PRODUCT_VERSION ->= Enterprise, Professional, Community, Express, or not set<br></div><div>MSV= C_TOOLSET_VERSION=C2=A0 -> This may only apply for MSVC2017 or above (or= could be used if MSVC_VERSION is not set for MSVC < 2017, though that w= ould likely introduce confusion</div><div><br></div><div>MSVC_SELECTOR ->= ; Callable (too allow more flexibility than static versions above)<br></div= ><div><br></div><div>Otherwise you end up encoding the information in a str= ing and then you have to decode it.</div><div>Seems more complicated than n= ecessary, and we don't have any other syntaxes embedded in variables th= us far.</div><div><br></div><div>I realize you have lots of time invested i= n your MSVC_VERSION implementation you've explained, but the goal here = is to be consistent with expected behavior in the face of changed MSVC.</di= v><div><br></div><div>(And yes. I know.. "Foolish consistency is the h= obgoblin of little minds", but I think in this case it's not fooli= sh)</div><div><br></div><div>Welcome feedback on above.<br></div><div><br><= /div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><di= v dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 9, 2020 at 2:50 PM Joseph Br= ill <<a href=3D"mailto:[email protected]" target=3D"_blank">josep= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= ;padding-left:1ex"><div dir=3D"ltr"><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"><span style=3D"font-size:17= .9776px">This email is an attempt to focus the discussion concerning=C2=A0s= upport for MSVC toolsets moving forward in a rational, dispassionate discou= rse.</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">I am advocating a minor shift in orientation or = "world view" for MSVC 2017 and later: the semantic transition fro= m thinking of the msvc version as a product to thinking of the msvc version= as a toolset.=C2=A0 This actually makes the implementation of toolset supp= ort easier.</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"><span style=3D"font-size:17.9776px">There is a w= orking version of the support for </span>toolsets<span style=3D"font-size:1= 7.9776px"> at varying levels of precision that can be enabled and disabled.= =C2=A0 The intent is that a command-line switch could be added to enable th= e toolset specific capabilities.=C2=A0 By default, the toolset specific cap= abilities would be disabled in which case the code behaves exactly like </s= pan>the<span style=3D"font-size:17.9776px">=C2=A0current master.=C2=A0 This= would allow field testing and evaluation of the functionality in other env= ironments and to easily test the=C2=A0differences between the current maste= r and the toolset functionality.=C2=A0 The functional aspects are feature c= omplete.=C2=A0 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.</span></p><p style=3D"margin:0.5rem 0px 1rem;color= :rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI&= quot;,Helvetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol",&quo= t;Apple Color Emoji";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 b= e time limited in the near term and due in part to the existing discussion = unraveling fairly quickly with dim=C2=A0prospects of inclusion moving forwa= rd.=C2=A0=C2=A0</span><span style=3D"font-size:17.9776px">Despite being clo= sed, I recommend viewing the "documentation" (the PR text and the= first comment) and the vc.py code difference in PR #3717.=C2=A0 At any tim= e the PR request can be reopened.=C2=A0 I would need a git guru to walk me = through associating the new branch name with the "old" PR.</span>= </p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-app= le-system,BlinkMacSystemFont,"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 knoc= ks an item or two off the internal vc.py TODO list such as a single vswhere= =C2=A0query and processing the json results for all known installations.=C2= =A0 Ranked toolset lists are constructed by host/target.=C2=A0 The ranking = takes into account the toolset version and product type.=C2=A0 A single too= lset instance may be a member of multiple toolset lists.=C2=A0 Expensive lo= okups are "runtime memoized/cached" so that they are only compute= d once.=C2=A0 While there is a fair amount of initialization, the processin= g burden is based on the number of products installed and the number of too= lsets for each product.=C2=A0 Typical environments likely have a single pro= duct installation with a spartan number of different toolsets installed. Th= ere is nothing particularly "clever" done in the implementation a= nd should not be a maintenance burden.=C2=A0 The bulk of the toolset suppor= t 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 appr= oximately=C2=A01400 lines of code.</span><br></p><p style=3D"margin:0.5rem = 0px 1rem;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,&= quot;Segoe UI",Helvetica,Helvetica,Arial,sans-serif,"Segoe UI Sym= bol","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 msvc=C2=A0<em>toolset</em>. 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.=C2=A0 That changed with = the release of MSVC 2017 which allows multiple side-by-side toolset install= ations by target.=C2=A0=C2=A0<span style=3D"font-size:17.9776px">MSVC 2017 = and later, can be 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 2019 installation can be viewed as a container for 14.1X, 14.= 2X, and transparently the 14.0 toolsets).=C2=A0 Moving forward, I believe t= hat it will be advantageous to change from a=C2=A0</span><span style=3D"fon= t-size:17.9776px"><em>product</em></span><span style=3D"font-size:17.9776px= ">=C2=A0orientation to a <i>toolset</i> orientation.=C2=A0 This change is o= nly for 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= -family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Hel= vetica,Arial,sans-serif,"Segoe UI Symbol","Apple Color Emoji= ";font-size:17.9776px"></p><p style=3D"margin:0.5rem 0px 1rem;color:rg= b(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI&quo= t;,Helvetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","A= pple Color Emoji";font-size:17.9776px">With MSVC 2017 and MSVC 2019, a= n SCons version request of "14.1" or "14.2", respective= ly,=C2=A0<em>is a toolset request</em>=C2=A0that cannot be specified at a f= iner granularity. The current msvc behavior uses the=C2=A0<em>default tools= et</em>=C2=A0which is generally the newest installed=C2=A0<em>toolset</em>= =C2=A0version when the "--vcvars_ver" argument is not specified f= or the vcvars batch file.</p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(5= 1,51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",= Helvetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","Appl= e Color Emoji";font-size:17.9776px">For example, a version request of = "14.1" is likely to use the "14.16.27023" toolset when = MSVC 2017 is installed. Effectively, the=C2=A0<em>product request</em>=C2= =A0is a=C2=A0<em>toolset request</em>=C2=A0identical to "find the newe= st toolset version installed that starts with '14.1'". However= , "14.2" (MSVC 2019) will return a=C2=A0<em>toolset</em>=C2=A0bas= ed on the latest update which likely varies across users and computers.=C2= =A0 Currently, a request for "14.1" will fail if MSVC 2019 is ins= talled with the 14.1 toolset.=C2=A0 With a toolset orientation, a 14.1 tool= set 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 spe= cified toolset for a given host/target combination.=C2=A0 This two-stage qu= ery, if necessary, is implemented in the working toolset oriented version.<= /p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-appl= e-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,= sans-serif,"Segoe UI Symbol","Apple Color Emoji";font-s= ize:17.9776px">Currently, the actual toolset versions used for 2017 and 201= 9 are based on end-user's installation options and frequency of updates= . 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>. Simil= arly, the installed toolset version is not necessarily the same for all hos= t/target combinations within a given product installation.=C2=A0 T<span sty= le=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 environments,= 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 style=3D"= margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-family:-apple-system,BlinkM= acSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-serif,&quo= t;Segoe UI Symbol","Apple Color Emoji";font-size:17.9776px">= <span style=3D"font-size:17.9776px">There may be many reasons (e.g., enterp= rise and/or customer requirements) that build scripts are tied to a specifi= c toolset.=C2=A0 If a build depends on the 14.1=C2=A0</span><em style=3D"fo= nt-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-size:17.9= 776px">product</em><span style=3D"font-size:17.9776px">=C2=A0container it i= s installed from an end-user's perspective given the two-stage selectio= n rule described=C2=A0earlier.=C2=A0 Given the same=C2=A0toolset, the produ= ced binaries should be binary compatible independent of the product install= ation.=C2=A0 The same issue will arise when the next MSVC=C2=A0</span><em s= tyle=3D"font-size:17.9776px">product</em><span style=3D"font-size:17.9776px= ">=C2=A0is released and end-users desire to use the 14.2X=C2=A0</span><em s= tyle=3D"font-size:17.9776px">toolset</em><span style=3D"font-size:17.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-system,Blink= MacSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-serif,&qu= ot;Segoe UI Symbol","Apple Color Emoji";font-size:17.9776px"= >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.=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,Bl= inkMacSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,sans-serif,= "Segoe UI Symbol","Apple Color Emoji";font-size:17.9776= px">This could have a tangible side-effect of making build scripts more por= table: the build scripts can be tied to a toolset rather than a toolset/pro= duct combination.=C2=A0 Although if it is desired to specify the toolset/pr= oduct combination that is supported as well.</p><p style=3D"margin:0.5rem 0= px 1rem;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,&q= uot;Segoe UI",Helvetica,Helvetica,Arial,sans-serif,"Segoe UI Symb= ol","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-family:-apple= -system,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvetica,Arial,s= ans-serif,"Segoe UI Symbol","Apple Color Emoji";font-si= ze:17.9776px"><li style=3D"margin:0.6em 0.2em 0.6em 1em">specifying an indi= vidual toolset at varying degrees of precision:<ul style=3D"margin:1.1em 0p= x"><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-style:outside none square= ">"14.1"</li><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-style= :outside none square">"14.16"</li><li style=3D"margin:0.6em 0.2em= 0.6em 1em;list-style:outside none square">"14.16.27"</li><li sty= le=3D"margin:0.6em 0.2em 0.6em 1em;list-style:outside none square">"14= .16.27023"</li></ul></li><li style=3D"margin:0.6em 0.2em 0.6em 1em">sp= ecifying individual product types (attached to a specific toolset=C2=A0<spa= n style=3D"font-weight:600">or</span>=C2=A0a product):<ul style=3D"margin:1= .1em 0px"><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-style:outside none= square">Enterprise: "14.26Ent"</li><li style=3D"margin:0.6em 0.2= em 0.6em 1em;list-style:outside none square">Professional: "14.2Pro&qu= ot;</li><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-style:outside none s= quare">Community: "14.26.27Com"</li><li style=3D"margin:0.6em 0.2= em 0.6em 1em;list-style:outside none square">Build Tools: "14.2BT"= ;</li><li style=3D"margin:0.6em 0.2em 0.6em 1em;list-style:outside none squ= are">Express: "14.1Exp"</li></ul></li><li style=3D"margin:0.6em 0= .2em 0.6em 1em">a right assignment operator ("->") that maps a= specific toolset to a defined product version with an optional product typ= e:<ul style=3D"margin:1.1em 0px"><li style=3D"margin:0.6em 0.2em 0.6em 1em;= list-style:outside none square">"14.0->14.2" use the the 14.0 = toolset via a 2019 installation</li><li style=3D"margin:0.6em 0.2em 0.6em 1= em;list-style:outside none square">"14.1->14.2BT" 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:outside none square">"14.1->14.2Com"= ; 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.9776px= ;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetic= a,Helvetica,Arial,sans-serif,"Segoe UI Symbol","Apple Color = Emoji""><span style=3D"font-size:17.9776px">The translation of the ext= ended version specification to a supplementary internal data structure is d= one in exactly one source code location: msvc_setup_env</span><span style= =3D"font-size:17.9776px">.=C2=A0 All existing code continues to operate on = the "NN.M" format for MSVC_VERSION as before.=C2=A0 Existing msvc= /msvs test suites pass all tests.=C2=A0 However, issues with the extended f= ormat being used prior to entry in vc.py=C2=A0script have yet to be identif= ied, if any.=C2=A0 The working version is completely self-contained in the = vc.py script.</span></p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,= 51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helve= tica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","Apple Col= or Emoji";font-size:17.9776px">Without a product qualifier (e.g., &quo= t;BT"), there is a=C2=A0<em>subtle but significant</em>=C2=A0change se= mantically: the product selected will be the newest/latest toolset that mat= ches the user specification within installed toolsets for a given (host,tar= get) combination. Effectively, without a product qualifier, any product typ= e could be returned based on the installed toolsets. This only affects mult= iple installations of the same product version (e.g., 14.1 and 14.Exp and/o= r 14.2Com and 14.2BT).=C2=A0 For end users that only have one product insta= lled, 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,BlinkMacSystem= Font,"Segoe UI",Helvetica,Helvetica,Arial,sans-serif,"Segoe = UI Symbol","Apple Color Emoji";font-size:17.9776px">This mea= ns that a user does not need to specify "14.1Exp" explicitly if t= here 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. I= n local testing, "14.1Exp" was returned for an "arm" ta= rget. In the local installations of 14.1 Community and 14.1 Express, the &q= uot;newest" toolset for an arm target was in the 14.1 Express installa= tion as it was installed the most recently.=C2=A0=C2=A0<span style=3D"font-= size:17.9776px">With a product qualifier, a specific product version and ty= pe is selected.</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"><span style=3D"font-size:17.9776px">T= o be clear, I do not need any fixes, enhancements, and am not reporting any= bugs.=C2=A0 The toolset version development was done in the spirit of cont= ributing to software that I have used since 2.X.=C2=A0 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.=C2=A0 I</span><span styl= e=3D"font-size:17.9776px">=C2=A0was motivated by both the post in the scons= users mailing list shown below and issue #3664.=C2=A0 As I am familiar wit= h 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,51)= ;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetic= a,Helvetica,Arial,sans-serif,"Segoe UI Symbol","Apple Color = Emoji";font-size:17.9776px"><span style=3D"font-size:17.9776px">Regard= s,</span></p><p style=3D"margin:0.5rem 0px 1rem;color:rgb(51,51,51);font-fa= mily:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Helvet= ica,Arial,sans-serif,"Segoe UI Symbol","Apple Color Emoji&qu= ot;;font-size:17.9776px">Joe</p><p style=3D"margin:0.5rem 0px 1rem;color:rg= b(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI&quo= t;,Helvetica,Helvetica,Arial,sans-serif,"Segoe UI Symbol","A= pple Color Emoji";font-size:17.9776px"><a href=3D"https://pairlist4.pa= ir.net/pipermail/scons-users/2020-June/008216.html" target=3D"_blank">https= ://pairlist4.pair.net/pipermail/scons-users/2020-June/008216.html</a>=C2=A0= =C2=A0<br></p><pre style=3D"white-space:pre-wrap;color:rgb(0,0,0)">><i> = The problem is scons don't find any 14.1(2017) installation, he only fi= nd </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" target=3D"_blank= ">https://github.com/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> _______________________________________________<br> Scons-dev mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= g</a><br> <a href=3D"https://pairlist2.pair.net/mailman/listinfo/scons-dev" rel=3D"no= referrer" target=3D"_blank">https://pairlist2.pair.net/mailman/listinfo/sco= ns-dev</a><br> </blockquote></div> _______________________________________________<br> Scons-dev mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= g</a><br> <a href=3D"https://pairlist2.pair.net/mailman/listinfo/scons-dev" rel=3D"no= referrer" target=3D"_blank">https://pairlist2.pair.net/mailman/listinfo/sco= ns-dev</a><br> </blockquote></div> --000000000000d9062305ac8ecac2-- --===============8582787293138903647== 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 --===============8582787293138903647==--