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