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.br...@gmail.com> wrote: > On Tue, Aug 11, 2020 at 10:52 PM Jason Kenny <dragon...@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. > > > > *…* > >
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
