Re: [Scons-dev] MSVC 2017+ Toolset Support
On 8/10/20 6:03 PM, Joseph Brill wrote: > 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. Only minor correction: you can get eight via just the standard installer - build tools 2017 is not rare at all; while express (yes, "expressly" discontinued after 2017) is quite hard to find, and you can't get at it through the standard VS installer - until you actually have it installed, then the installed VS 2017 installer will let you manipulate it, but it's invisible otherwise. > It is possible to specify the 2015 toolset (14.0) via MSVC 2017 and MSVC > 2019 as well. the installation policy seems to be you get one toolset version from the previous major release, only. I don't "know" this (as I've read no doc or anything), deducing this from looking at my one machine with a bunch of different VCs installed: the 2017 VS Installer offers me "2015.3 v14.00" v140 toolset, along with v141 14.11 through 14.16. The 2019 VS installer offers me v141 14.16, along with v142 14.20 through 14.27 - note no toolset for 2015 here. all this is probably getting down to "more than anyone wants to know" :) ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] MSVC 2017+ Toolset Support
> "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 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 > 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.
Re: [Scons-dev] MSVC 2017+ Toolset Support
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 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
