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

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] 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 wrote:

...

On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost < boost@lists.boost.org> 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 +44 (0) 1539 561830