[Scons-dev] MSVC 2017+ Toolset Support

[Joseph Brill]

On Tue, Aug 11, 2020 at 10:52 PM Jason Kenny <dragon512 at live.com> wrote:

> Just to chime in.. my understanding of the vc compiler is that it is the
> same for all these cases. The community, profession and enterprise is about
> extra paid features of the IDE. While these are all side by side
> installable.. the code you build, as I understand, is the same. For me at
> least I don’t see what value exists yet in selecting license level values
> of the MSVS
>

*All – please respond with any corrections and clarifications if anything
below is inaccurate or misleading. *



In general, this assessment is accurate.  With respect to the current SCons
implementation however, an important qualification is necessary and is
illustrated below.



There is a potentially rare problem that only manifests itself when
multiple product instances (i.e., Enterprise, Professional, Community, and
Build Tools) of the same version are installed due to the current instance
selection implementation for 2017 and 2019 based on the vswhere tool.



Given two or more installations of Enterprise, Professional, and
Community:  the expected build *behavior is the same given that the
installed features and target toolsets are the same*.



Given two or more installations of Enterprise, Professional, and
Community:  the expected build behavior *can be different if the installed
features or target toolsets are different*.  Herein lies the rub.



Currently, the selected MSVS instance is independent of the required
host/target architecture and toolset for the build.  With multiple
instances of the same product installed, it is possible an installed
instance is selected that does not fulfill the required features/toolsets
despite the presence of installed instances that do fulfill the required
features/toolsets.



Consider the following installations of MSVS 2019:

- MSVS 2019 Enterprise: only toolsets targeting windows x64/x86

- MSVS 2019 Community: only toolsets targeting arm/arm64.



In this case:

- If 2019 Enterprise is always returned: arm/arm64 builds would fail

- If 2019 Community is always returned: x64/x86 builds would fail



The Visual Studio Installer offers a smorgasbord of independently selected
features (e.g., ATL, MFC), targets (e.g., arm, arm64), and toolsets.
Toolsets can be identified by the folder layout and existence of
tool binaries within an MSVS installation.  Features are likely difficult
or impossible to identify.



It could be possible that an end-user may not want to modify a corporate/IT
supplied Enterprise instance or may be restricted from making changes.  In
this case, installing the Community edition makes sense.  For example,
x86/x64 software for work and arm/arm64 software for pleasure.



Similar examples with “features” could apply as well: one instance might
have ATL+MFC support installed while another instance does not.  In this
case, there would be a problem if the instance without ATL+MFC were
selected.



Given multiple instances installed with the same products and features, it
may be desirable to install updates (e.g., minor toolset updates) in one
instance and test with that particular instance prior to propagating the
same updates to the other instances.   While extremely rare, code
generation bugs are possible in a minor toolset update. Reliance on
“undocumented” features also can also be problematic when switching
products and toolsets.  With a corporate/it managed instance, updates may
be less frequent than a user-managed instance.



Given two or more instances installed, it may be desirable to force a build
using the same product type as a customer and/or a production build
environment for purposes of verification and validation.



If nothing else, it is useful for testing SCons J



I am unaware of any documentation that describes the order in which vswhere
would return instances of Enterprise, Professional, and Community if all
three were present.  Alphabetical? Last installed to first installed?
License level?  I don't have access to licensed versions of the Enterprise
and Professional products.


With respect to the current SCons implementation, expansion of the
user-defined product specification would be useful even without specific
toolset version support for the situations outlined above.



The mechanism necessary to be able to select the “Build Tools” instance
when one or more Enterprise/Professional/Community instances is likely
general enough to be extended to cover all instances at little to no extra
cost.



As for generated output, starting with 2015 all of the product instances
(i.e., Enterprise, Professional, Community, Build Tools, and Express) are
binary compatible both within a toolset (e.g, v141) and across toolsets
(e.g, v140, v141, and v142) subject to limitations.  See below.



Regards,

Joe



https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2019#:~:text=The%20Microsoft%20C%2B%2B%20(MSVC)%20compiler,executables%20built%20by%20different%20versions.&text=You%20can%20still%20use%20them,Visual%20Studio%202017%20or%202019.



…



*C++ binary compatibility between Visual Studio 2015, 2017, and 2019*



The Microsoft C++ (MSVC) compiler toolsets in Visual Studio 2013 and
earlier don't guarantee binary compatibility across versions. You can't
link object files, static libraries, dynamic libraries, and executables
built by different versions. The ABIs, object formats, and runtime
libraries are incompatible.



We've changed this behavior in Visual Studio 2015, 2017, and 2019. The
runtime libraries and apps compiled by any of these versions of the
compiler are binary-compatible. It's reflected in the C++ toolset major
number, which is 14 for all three versions. (The toolset version is v140
for Visual Studio 2015, v141 for 2017, and v142 for 2019). Say you have
third-party libraries built by Visual Studio 2015. You can still use them
in an application built by Visual Studio 2017 or 2019. There's no need to
recompile with a matching toolset. The latest version of the Microsoft
Visual C++ Redistributable package (the Redistributable) works for all of
them.



There are three important restrictions on binary compatibility:

   - You can mix binaries built by different versions of the toolset.
   However, you must use a toolset at least as recent as the most recent
   binary to link your app. Here's an example: you can link an app compiled
   using the 2017 toolset to a static library compiled using 2019, if they're
   linked using the 2019 toolset.
   - The Redistributable your app uses has a similar binary-compatibility
   restriction. When you mix binaries built by different supported versions of
   the toolset, the Redistributable version must be at least as new as the
   latest toolset used by any app component.
   - Static libraries or object files compiled using the /GL (Whole program
   optimization)
   <https://docs.microsoft.com/en-us/cpp/build/reference/gl-whole-program-optimization?view=vs-2019>
compiler
   switch *aren't* binary-compatible across versions. All object files and
   libraries compiled using /GL must use exactly the same toolset for the
   compile and the final link.



*…*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20200814/e9911a0f/attachment.html>