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

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

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

Boost - Dev mailing list
Sorry to say the beta release of 1.64.0 is hereby going to be delayed for
at least another week. The confusion of VS2017 version numbers and the
communities inability to address this issue after the beta is to blame.

To address the situation the beta release will be published when one of the
two tasks below are completed:

(A) Boost Config changes to use 1410 as the autolink version to match what
the currently working generated libs are taggeg with.

Or:

(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).


--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

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

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

Boost - Dev mailing list


On 17/03/2017 15:12, Rene Rivera via Boost wrote:
> Sorry to say the beta release of 1.64.0 is hereby going to be delayed for
> at least another week. The confusion of VS2017 version numbers and the
> communities inability to address this issue after the beta is to blame.
>
> To address the situation the beta release will be published when one of the
> two tasks below are completed:
>
> (A) Boost Config changes to use 1410 as the autolink version to match what
> the currently working generated libs are taggeg with.

I've cherry picked the relevant commits to master and pushed those - so
Config and Build are consistent now.

However, IMO the name used is just plain wrong - note that both Peter
Dimov and myself have both typed in the "wrong" name by mistake *even
when we know what the "right" name is*.  Worse, if you do type in
toolset=msvc-14.1 by mistake, something (not sure what) still happens
and libraries with a "141" suffix are generated, IMO we need to fix that
before release, though not necessarily before beta.

John.


>
> Or:
>
> (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).
>
>


---
This email has been checked for viruses by AVG.
http://www.avg.com


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

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/17/2017 11:12 AM, Rene Rivera via Boost wrote:

> Sorry to say the beta release of 1.64.0 is hereby going to be delayed for
> at least another week. The confusion of VS2017 version numbers and the
> communities inability to address this issue after the beta is to blame.
>
> To address the situation the beta release will be published when one of the
> two tasks below are completed:
>
> (A) Boost Config changes to use 1410 as the autolink version to match what
> the currently working generated libs are taggeg with.
>
> Or:
>
> (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 have discovered that Visual Studio 2017 itself actually has no current
documentation available, so even Microsoft has released its own product
before it should even have been released. Therefore I think you are
doing the absolutely correct thing and there is no point in trying to
rush Boost 1.64 until the issue with VS2017 version numbers are tested
and resolved. Thanks for all the work that you and others have done and
are doing to resolve this issue.


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

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

Boost - Dev mailing list
On Fri, Mar 17, 2017 at 4:22 PM, Edward Diener via Boost
<[hidden email]> wrote:
>
> I have discovered that Visual Studio 2017 itself actually has no current
> documentation available, so even Microsoft has released its own product
> before it should even have been released. Therefore I think you are doing
> the absolutely correct thing and there is no point in trying to rush Boost
> 1.64 until the issue with VS2017 version numbers are tested and resolved.
> Thanks for all the work that you and others have done and are doing to
> resolve this issue.
>

+1, my gratitude/appreciation also to Rene and everyone involved in
this release.

Does master open up for changes after the beta release on Wednesday,
or earlier/now, due to the delay?

(I almost expected we would release and wait for 1.65 to support VS2017 fully).

Glen

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

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

Boost - Dev mailing list
On Fri, Mar 17, 2017 at 7:57 PM, Glen Fernandes via Boost <
[hidden email]> wrote:

>
> Does master open up for changes after the beta release on Wednesday,
> or earlier/now, due to the delay?
>

We are more likely to say yes to master merge requests with the delay. But
you still need permission. After the beta it will be entirely open, as
usual.


--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

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

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Mar 17, 2017 at 1:08 PM, John Maddock via Boost <
[hidden email]> wrote:

>
>
> On 17/03/2017 15:12, Rene Rivera via Boost wrote:
>
>> Sorry to say the beta release of 1.64.0 is hereby going to be delayed for
>> at least another week. The confusion of VS2017 version numbers and the
>> communities inability to address this issue after the beta is to blame.
>>
>> To address the situation the beta release will be published when one of
>> the
>> two tasks below are completed:
>>
>> (A) Boost Config changes to use 1410 as the autolink version to match what
>> the currently working generated libs are taggeg with.
>>
>
> I've cherry picked the relevant commits to master and pushed those - so
> Config and Build are consistent now.
>

I don't think this happened...it looks like master auto_link.hpp is using
vc141 not vc1410. Develop looks like it matches what build is doing.

https://github.com/boostorg/config/blob/master/include/boost/config/auto_link.hpp#L172

IMO this is still blocking beta.


>
> However, IMO the name used is just plain wrong - note that both Peter
> Dimov and myself have both typed in the "wrong" name by mistake *even when
> we know what the "right" name is*.  Worse, if you do type in
> toolset=msvc-14.1 by mistake, something (not sure what) still happens and
> libraries with a "141" suffix are generated, IMO we need to fix that before
> release, though not necessarily before beta.
>

I agree. Most users won't even know to try 14.?? to use VS 2017, because MS
clearly labels it everwhere as "15", but it is definitely more correct for
us to match MS's c++ tools than the visual studio version. Anyway, once
users figure that out, they'll be much more likely to use 14.1 vs.
14.10...there was no 14.2, 14.3, 14.9 etc!

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

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

Boost - Dev mailing list
In reply to this post by Boost - Dev 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] 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 <[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!

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













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

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Tom Kent wrote:

> 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

+1.


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

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

Boost - Dev mailing list
In reply to this post by Boost - Dev 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
 On 20 March 2017 at 13:43, Refael Ackermann via Boost
<[hidden email]> wrote:

> 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!
>
>
> 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).

I don't think this is argument holds strong in practice.
AFAIK, PlatformToolseVersion and its derivatives used in Boost
are never compared as range, like _MSC_VER often is,
but as exact values.

Boost tests for:
v140
v141
and, if at any time Microsoft replaces it with, STL (tm):
meow
let it be so.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

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

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

Boost - Dev mailing list
Folks, I'm just now looking at this thread. Rafael kindly pinged me on GitHub--I don't normally pay attention to the Boost list.

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

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
[Mateusz Loskot]

> I don't think this is argument holds strong in practice.
> AFAIK, PlatformToolseVersion and its derivatives used in
> Boost are never compared as range, like _MSC_VER often is,
> but as exact values.
> Boost tests for:
> v140
> v141
> and, if at any time Microsoft replaces it with, STL (tm):
> meow
> let it be so.

FYI, we're planning to release a toolset that will be binary-incompatible with v140 and v141 at some point in the future (the libraries, and probably the compiler too, will be bin-incompatible, to allow us to make significant improvements to data structure layout and so forth that we're otherwise unable to make).

We haven't decided on that toolset's versioning at this point. (I expect/hope that it will be very distinctive and not easily confused with the current versions; Visual C++ vMeow does have a nice ring to it...)

STL

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

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

Boost - Dev mailing list
On 20 March 2017 at 22:17, Stephan T. Lavavej
<[hidden email]> wrote:

> [Mateusz Loskot]
>> I don't think this is argument holds strong in practice.
>> AFAIK, PlatformToolseVersion and its derivatives used in
>> Boost are never compared as range, like _MSC_VER often is,
>> but as exact values.
>> Boost tests for:
>> v140
>> v141
>> and, if at any time Microsoft replaces it with, STL (tm):
>> meow
>> let it be so.
>
> FYI, we're planning to release a toolset that will be binary-incompatible with v140 and v141 at some point in the future (the libraries, and probably the compiler too, will be bin-incompatible, to allow us to make significant improvements to data structure layout and so forth that we're otherwise unable to make).

Thanks Stephan, I always appreciate all the updates and clarifications you give.

> We haven't decided on that toolset's versioning at this point. (I expect/hope that it will be very distinctive and not easily confused with the current versions; Visual C++ vMeow does have a nice ring to it...)

+1

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

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

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Sorry all, I meant to send this to the list but only replied to Daniel.
This adds an option 4 and 5.

On Sun, Mar 19, 2017 at 3:58 PM, Tom Kent <[hidden email]> wrote:

>
>
> On Sun, Mar 19, 2017 at 10:17 AM, Daniel James <[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.
>>
>
> So 2-a would meet these requirements. However, I did overlook the mixed
> options:
>
> Option 4 (141 and 14.10) -
> build bootstrap would use bootstrap.bat vc141
> build of source would use b2 toolset=msvc-14.10
> build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_
> 64.lib
> config would auto-link libraries of the same format
> (4-a is the same as 2-a)
>
> Option 5 (1410 and 14.1) -
> build bootstrap would use bootstrap.bat vc1410
> build of source would use b2 toolset=msvc-14.1
> build would generat libraries of the format libboost_NAME_vc1410-OPTIONS-
> 1_64.lib
> config would auto-link libraries of the same format
> (5-a is the same as 1-a)
>
> Tom
>
>

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

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 20/03/2017 03:52, Paul A. Bristow wrote:
>> I am in favor of option 2. - as the least worst.
>
> +1
>
> NAME == $(PlatformToolsetVersion)

+1 from me too.

> Option 4 (141 and 14.10) -
> build bootstrap would use bootstrap.bat vc141
> build of source would use b2 toolset=msvc-14.10
> build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_
> 64.lib
> config would auto-link libraries of the same format
> (4-a is the same as 2-a)

This also makes a certain amount of sense but I worry that 14.10 is
potentially more confusing as it seems inconsistent with the other
values, despite being technically more "correct".  As John Maddock noted
it's easy to get wrong at present even when you know what's correct.

> 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?

There is a way to do that currently using the build id:
   http://stackoverflow.com/a/42408982/43534

I agree that it would be nice if it happened automatically, though.



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

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera <[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.
>

OK.. Is there a consensus on this now? What is it?

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

I see PRs for the 14.1 & 141 changes thanks to Tom, and John. But no other
PRs. Does that mean that's the default choice? I.e. Can someone summarize
the state of the great version fiasco? :-)

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12
Loading...