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: Paul A. Bristow (pbristow_at_[hidden])
Date: 2017-03-19 14:52:02

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Tom Kent via Boost
> Sent: 19 March 2017 13:15
> To: Boost Developers List; Boost.Build developer's and user's list
> Cc: Tom Kent
> Subject: Re: [boost] [release] 1.64.0 Delayed because of Microsoft (version numbers)
> 
> 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!

What a shambles :-(

> I am in favor of option 2. - as the least worst.

+1

NAME == $(PlatformToolsetVersion)

Paul

PS What happened to plans to change the name to include the address-model?
(So that all the library files can be dumped into one folder).

Although I am now quite happy using two folders that I have called /win32 and /x64  (both fairly daft names but with at least a tiny
amount of logic), it requires a cunning boost.props file to make it work invisibly, and a more complex build .bat to push the two
variants into the right folder.

Isn't the whole (excellent) idea of auto-linking to make it simple?

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]