Quantcast

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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Build mailing list


On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Build mailing list


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


On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost <[hidden email]> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
On 19 March 2017 at 13:10, Tom Kent via Boost <[hidden email]> wrote:
>
> 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

[snip]

> 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".

[snip]

> I *think* that is all the reasonable options. Let the consensus form!

I disagree, I think we should limit ourselves to values that Microsoft
actually uses. As far as I'm aware, they don't use 1410, and they
don't use 14.1. There are already too many ways of writing the version
number, adding more will just add to the confusion.

We should also make as few assumptions about the correspondence
between different version numbers as possible. We shouldn't assume
that the toolset version is the compiler minus 5. Similarly the idea
that there's a fixed correspondence between whatever 141 and 14.10
represents, we should try to deal with the possibility 142 - 14.10,
141 - 14.11, 142 - 14.11 and 237 - 18.65, or whatever Microsoft does
10 years down the line.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
On Sun, 19 Mar 2017 08:10:37 -0500
Tom Kent via Boost <[hidden email]> wrote:

> On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost <
> [hidden email]> 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
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

I'm for Option 1.
Might be more "breaking" but I think it'll be more future proof (i.e. vc1412 > vc1410 && 14.20 > 14.12 14.10).
Also People will need to familiarise themselfs with $(VCToolsVersion) == "14.10.25017", as it's now part of cl.exe's path (e.g. "D:\bin\dev\VS\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe")

What a clusterf**k... MS, SHM...

--
Refael Ackermann <[hidden email]>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Build mailing list
In reply to this post by Boost - Build mailing list


On Sun, Mar 19, 2017 at 11:17 AM, Daniel James via Boost <[hidden email]> wrote:
On 19 March 2017 at 13:10, Tom Kent via Boost <[hidden email]> wrote:
>
> 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

[snip]

> 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".

[snip]

> I *think* that is all the reasonable options. Let the consensus form!

I disagree, I think we should limit ourselves to values that Microsoft
actually uses. As far as I'm aware, they don't use 1410, and they
don't use 14.1. There are already too many ways of writing the version
number, adding more will just add to the confusion.

+1
 

We should also make as few assumptions about the correspondence
between different version numbers as possible. We shouldn't assume
that the toolset version is the compiler minus 5. Similarly the idea
that there's a fixed correspondence between whatever 141 and 14.10
represents, we should try to deal with the possibility 142 - 14.10,
141 - 14.11, 142 - 14.11 and 237 - 18.65, or whatever Microsoft does
10 years down the line.

+1

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Marcel Raad
In reply to this post by Boost - Build mailing list
Boost - Build mailing list wrote
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
I don't care about the command-line option name, but I'm somewhat relying on the library name containing $(PlatformToolsetVersion). So of those three options, I would vote for option 2.
Loading...