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

Subject: Re: [boost] [release] 1.64.0 please test master snapshot..
From: Tom Kent (lists_at_[hidden])
Date: 2017-03-18 03:06:25

On Fri, Mar 17, 2017 at 7:29 AM, Mateusz Loskot via Boost <
boost_at_[hidden]> wrote:

> On 17 March 2017 at 09:10, Olaf van der Spek via Boost
> <boost_at_[hidden]> wrote:
> > On Fri, Mar 17, 2017 at 3:05 AM, Rene Rivera via Boost
> > <boost_at_[hidden]> 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.