Re: [boost] [release] 1.64.0 please test master snapshot..

On Fri, Mar 17, 2017 at 7:29 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

On 17 March 2017 at 09:10, Olaf van der Spek via Boost wrote:

...

On Fri, Mar 17, 2017 at 3:05 AM, Rene Rivera via Boost wrote:

...

...

$(PlatformToolsetVersion) is "141".

Personally I would prefer 14.10 (aka 1410) because of purely selfish reasons. As it would mean Boost Predef already says that "14.10" is the version. But otherwise I don't care what version number it is. I'm beyond exhausted from dealing with VS version numbers. Which means..

1. For the beta the version is "14.10", aka "1410". 2. And we'll apply the Boost Config patch accordingly. 3. After beta everyone can fight over what the "real" version number should be. 4. Apply changes after enough people agree. And if that's fast enough.. We can do another beta. Other we just wait for the release to have the change.

Where is 14.10 coming from?

NMAKE build utility, perhaps?

VS2017 is shipped with NMAKE.EXE /? Microsoft (R) Program Maintenance Utility Version 14.10.25017.0

I went through VS2017 and VS2015 to compare the macros that are available, here's what I found: Visual Studio 2017 Enterprise Default C++ Console Application project, Debug, x86 Default Platform Toolset - Project -> Properties -> Configuration Properties -> General -> Platform Toolset: Visual Studio 2017 (v141) Macros - Project -> Properties -> Configuration Properties -> C++ -> Additional Include Directories -> Edit -> Macros $(DefaultPlatformToolset) v141 $(PlatformToolset) v141 $(PlatformToolsetVersion) 141 $(Platform) Win32 $(PlatformArchitecture) 32 $(PlatformTarget) x86 $(TargetPlatformVersion) 10.0.14393.0 $(VCToolsVersion) 14.10.25017 $(VCToolArchitecture) Native32Bit $(MSBuildToolsVersion) 15.0 $(VCProjectVersion) 15.0 $(VisualStudioVersion) 15.0 Visaul Studio 2015 Enterprise Default C++ Console Application project, Debug, x86 Default Platform Toolset - Project -> Properties -> Configuration Properties -> General -> Platform Toolset: Visual Studio 2015 (v140) Macros - Project -> Properties -> Configuration Properties -> C++ -> Additional Include Directories -> Edit -> Macros $(DefaultPlatformToolset) v140 $(PlatformToolset) v140 $(PlatformToolsetVersion) 140 $(Platform) Win32 $(PlatformArchitecture) 32 $(PlatformTarget) x86 $(TargetPlatformVersion) 8.1 $(VCToolsVersion) N/A $(VCToolArchitecture) Native32Bit $(MSBuildToolsVersion) 14.0 $(VCProjectVersion) N/A $(VisualStudioVersion) 14.0 My (semi-)personal dog in the fight: For the binary builds that we've put on sourceforge, the libraries are organized in directories based on the b2 command that was used to build them. This b2 toolset=msvc-14.0 address-model=32 would make boost_1_XX_0/lib32-msvc-14.0/. This could then be added to Visual Studio's link path (across multiple project files for different compilers/architectures) with boost_1_XX_0/lib$( PlatformArchitecture)-msvc-$(VisualStudioVersion)/. Then the libraries in that directory were named with libboost_thread_vc140-X-1_XX.lib, which matched the output from the config/auto_link.hpp pragma, so the library names were automatically included. Short of making our toolset= set to the visual studio version instead of any c++ toolset, this isn't going to work anymore. Thanks MS! :-( Historically, this version change has never happened before. There *was* another .1 release Visual Studio .NET was 7.0 and had toolset vc70, Visual Studio .NET 2003 was 7.1 and had toolset vc71. With this .1 release, Microsoft at least kept the C++ version and greater visual studio version in lockstep, the current VS2017 situation is different.

From all the talk I've heard from MS about this being a big update, C++14, C++17, blah, blah, blah, I'm surprised they went and called it a minor version. It isn't minor enough that VS2015 programs can link against it, and if they wanted to indicate that VS2017 programs could link against VS2015 libs, they could have just said "it is now backwards compatible".

So frustrating.