Re: [boost] [release] 1.64.0 Delayed because of Microsoft (version numbers)

Subject: Re: [boost] [release] 1.64.0 Delayed because of Microsoft (version numbers)
From: Tom Kent (lists_at_[hidden])
Date: 2017-03-19 13:15:29

On Sun, Mar 19, 2017 at 8:10 AM, Tom Kent <lists_at_[hidden]> wrote:

>
>
> On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost <
> boost_at_[hidden]> wrote:
>
>> (B) The community decides what version number we should be using and the
>> appropriate PRs are filed and applied and tested for all the repos
>> involved. Which means:
>>
>> 1. The community has until 12:00 CDT US March 18 to decide on what the vc
>> version number and tag should be.
>>
>> 2. The community must post PRs for the places where we reference VS2017
>> version numbers to the new number. Those are at least:
>>
>> <https://github.com/boostorg/config>
>> <https://github.com/boostorg/build>
>> <https://github.com/boostorg/boost>
>> <https://github.com/boostorg/website>
>>
>> People have until 17:00 CDT Monday March 20 to submit those PRs.
>>
>> 3. The community can test the resulting master snapshot when available at
>> the latest 24:00 Monday March 20.
>>
>> 4. If all goes well we can have a beta release on Wednesday March 22 (ie
>> one week late).
>
>
> I'm not sure how we'll coalesce around a consensus, but I figure we should
> lay out the options in one place. Even if this doesn't make it into the
> beta, we should be clear on this going forward.
>
> Option 1 - 14.10 Use microsoft toolset version based on cl.exe version -5.
> This is the official version of the c++ toolset that microsoft has been
> pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017", this
> macro is not available in previous versions of visual studio.
>
> build bootstrap would use bootstrap.bat vc1410
> build of source would use b2 toolset=msvc-14.10
> build would generat libraries of the format libboost_NAME_vc1410-OPTIONS-
> 1_64.lib
> config would auto-link libraries of the same format
>
> Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses
> for their toolset version. The $(PlatformToolsetVersion) macro is "141". In
> VS2015 this was "140".
>
> build bootstrap would use bootstrap.bat vc141
> build of source would use b2 toolset=msvc-14.1
> build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_
> 64.lib
> config would auto-link libraries of the same format
>
> Option 3 - 15.0 Use the visual studio version. The $(VisualStudioVersion)
> macro is "15.0". In VS2015 this was "14.0".
>
> build bootstrap would use bootstrap.bat vc15
> build of source would use b2 toolset=msvc-15.0
> build would generat libraries of the format libboost_NAME_vc150-OPTIONS-1_
> 64.lib
> config would auto-link libraries of the same format
>
>
>
> A alternative that could be made to any of the options 1-3 option would be
> to bring the b2 toolset in line with whatever we chose for the name,
> replacing the "msvc-" with "vc". For example option 1-a would be:
>
> build bootstrap would use bootstrap.bat vc1410
> build of source would use b2 toolset=vc1410
> build would generat libraries of the format libboost_NAME_vc1410-OPTIONS-
> 1_64.lib
> config would auto-link libraries of the same format
>
>
>
> I *think* that is all the reasonable options. Let the consensus form!
>
> Tom
>

I am in favor of option 2.

Option 1 while most "correct" is waaaaay too far in the weeds for users. It
doesn't play well with any built in "macros".

It kills me that Option 3 isn't worthy, but this is completely microsoft's
fault. Splitting the C++ toolset from the visual studio version was a
terrible decision. There were better ways to indicate backwards
compatibility with 14.0.

The alternative for b2 toolset naming would be more consistent, but would
just cause too many problems. We probably should have made this match back
on VS.NET, but at that point we didn't know where microsoft was going with
these versions. I'd say we're stuck with what we have.

Tom