[Scons-dev] MSVC 2017+ Toolset Support

[Bill Deegan]

So to summarize the only (possible) difference between pro,ent,community
would be in whatever optional and/or updated components were installed for
each?

So selecting one over the other would be useful just to use those
differences (optional/selected tools/components available via the visual
studio installer).

Does anyone have pro, enterprise, and community (or more than just one of
those versions installed) that could do a dump of vswhere output to answer
the question of ordering?

Note that vswhere's source code is on github...



On Fri, Aug 14, 2020 at 7:40 AM Joseph Brill <joseph.c.brill at gmail.com>
wrote:

> 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/5abfdab8/attachment-0001.html>