[boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1

[Daniel James via Boost]

The release candidates for the 1.66.0 beta release are now available at:

<https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/>

The SHA256 checksums are as follows:

0e137e61069e95f61fe0e46aa4a5432e65e209e87d470ea3c15b0ea1327583ac
boost_1_66_0_b1_rc1.7z
eff4854c1a672830c55fd2323ebe42d5d83e0f7a3d0a9d354d8bf55289831fa0
boost_1_66_0_b1_rc1.tar.bz2
f4fb07aa1ec639707570e42a848796d9a8155f23d1ece0f0a6a0cbee99807038
boost_1_66_0_b1_rc1.tar.gz
d5f480441223f45427199697edbdd78145499084f835597247a452d2a7e1e798
boost_1_66_0_b1_rc1.zip

The in progress release notes are at:

<http://www.boost.org/users/history/in_progress.html>

And the documentation is at:

<http://www.boost.org/doc/libs/1_66_0_beta1/>

As always, the release managers would appreciate it if you download
the candidate of your choice and give building it a try. Please report
both success and failure, and anything else that is noteworthy.

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

[Tom Kent via Boost]

On Thu, Nov 16, 2017 at 4:39 AM, Daniel James via Boost <
bo...@lists.boost.org> wrote:

> The release candidates for the 1.66.0 beta release are now available at:
>
> <https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/>
>
> The SHA256 checksums are as follows:
>
> 0e137e61069e95f61fe0e46aa4a5432e65e209e87d470ea3c15b0ea1327583ac
> boost_1_66_0_b1_rc1.7z
> eff4854c1a672830c55fd2323ebe42d5d83e0f7a3d0a9d354d8bf55289831fa0
> boost_1_66_0_b1_rc1.tar.bz2
> f4fb07aa1ec639707570e42a848796d9a8155f23d1ece0f0a6a0cbee99807038
> boost_1_66_0_b1_rc1.tar.gz
> d5f480441223f45427199697edbdd78145499084f835597247a452d2a7e1e798
> boost_1_66_0_b1_rc1.zip
>
> The in progress release notes are at:
>
> <http://www.boost.org/users/history/in_progress.html>
>
> And the documentation is at:
>
> <http://www.boost.org/doc/libs/1_66_0_beta1/>
>
> As always, the release managers would appreciate it if you download
> the candidate of your choice and give building it a try. Please report
> both success and failure, and anything else that is noteworthy.
>
>

I'm seeing compile errors in Boost Python against msvc-11.0 (10.0 and 12.0
work!).

There are a lot of them, but they all seem to be related to this:

compile-c-c++
bin.v2\libs\python\build\msvc-11.0\release\address-model-64\link-static\threadapi-win32\threading-multi\object\life_support.obj
life_support.cpp
.\boost/python/detail/type_traits.hpp(102) : error C2143: syntax error :
missing ';' before '='
.\boost/python/detail/type_traits.hpp(102) : error C2873: 'true_' : symbol
cannot be used in a using-declaration
.\boost/python/detail/type_traits.hpp(102) : error C2513: 'int' : no
variable declared before '='
.\boost/python/detail/type_traits.hpp(103) : error C2143: syntax error :
missing ';' before '='
.\boost/python/detail/type_traits.hpp(103) : error C2873: 'false_' : symbol
cannot be used in a using-declaration
.\boost/python/detail/type_traits.hpp(103) : error C2513: 'int' : no
variable declared before '='

call
"C:\Users\tomkent\AppData\Local\Temp\2\b2_msvc_11.0_vcvarsall_amd64.cmd"
>nul
cl /Zm800 -nologo
@"bin.v2\libs\python\build\msvc-11.0\release\address-model-64\link-static\threadapi-win32\threading-multi\object\life_support.obj.rsp"

...failed compile-c-c++
bin.v2\libs\python\build\msvc-11.0\release\address-model-64\link-static\threadapi-win32\threading-multi\object\life_support.obj...


toolset arch compile Link Execute
msvc-8.0 32 X X X
msvc-8.0 64 X X X
msvc-9.0 32 X X X
msvc-9.0 64 X X X
msvc-10.0 32 X X X
msvc-10.0 64 X X X
msvc-11.0 32 FAIL
msvc-11.0 64 FAIL
msvc-12.0 32 X X X
msvc-12.0 64 X X X
msvc-14.0 32 X X X
msvc-14.0 64 X X X
msvc-14.1 32 X X X
msvc-14.1 64 X X X

Compile means that the b2 command completed without errors
Link means that visual studio was able to link a sample executable to a
library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib)
generated
Execute means that the linked program executed without errors.


The full build log can be found here:
https://gist.github.com/teeks99/3a8026b06cd53ef2746a4e08bff1a026

[Stefan Seefeld via Boost]

Hi Tom,

thanks for raising this issue.

It looks like we falsely assume the compiler understands C++11 and thus
use attempt to use std::integral_constant. Could it be that the
conditional in
https://github.com/boostorg/python/blob/develop/include/boost/python/detail/type_traits.hpp#L10-L11
is wrong ? (If it was set to 'true' for MSVC 10.0, and 'false' for MSVC
>= 11.0 , when it should in fact be 'true' for MSVC 11.0, too, this
might explain the error. But given that I'm not very familiar with MSVC,
this is pure speculation. I'd appreciate any help from some Windows
experts.)

Thanks,

Stefan

--

...ich hab' noch einen Koffer in Berlin...

[Peter Dimov via Boost]

Stefan Seefeld wrote:
> It looks like we falsely assume the compiler understands C++11 and thus
> use attempt to use std::integral_constant. Could it be that the
> conditional in
> https://github.com/boostorg/python/blob/develop/include/boost/python/detail/type_traits.hpp#L10-L11
> is wrong ?

You should probably be checking BOOST_NO_CXX11_HDR_TYPE_TRAITS there unless
you have a specific reason not to do so.

[Daniel James via Boost]

On 16 November 2017 at 15:10, Peter Dimov via Boost

<bo...@lists.boost.org> wrote:
> Stefan Seefeld wrote:
>>
>> It looks like we falsely assume the compiler understands C++11 and thus
>> use attempt to use std::integral_constant. Could it be that the conditional
>> in
>> https://github.com/boostorg/python/blob/develop/include/boost/python/detail/type_traits.hpp#L10-L11
>> is wrong ?
>
>
> You should probably be checking BOOST_NO_CXX11_HDR_TYPE_TRAITS there unless
> you have a specific reason not to do so.

Yes, but I think the error is because it doesn't understand the C++11
type alias. Better to use:

typedef std::integral_constant<bool, true> true_;
typedef std::integral_constant<bool, false> false_;

According to MSDN, std::integral_constant was in Visual Studio 2008,
which is Visual C++ 9.

[Olaf van der Spek via Boost]

On Thu, Nov 16, 2017 at 11:39 AM, Daniel James via Boost
<bo...@lists.boost.org> wrote:
> As always, the release managers would appreciate it if you download
> the candidate of your choice and give building it a try. Please report
> both success and failure, and anything else that is noteworthy.

PS C:\vc\boost> .\bootstrap.bat
Building Boost.Build engine

Failed to build Boost.Build engine.
Please consult bootstrap.log for further diagnostics.

You can try to obtain a prebuilt binary from

http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.

**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.4.3
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x86'
###
### Using 'vc141' toolset.
###

C:\Users\Olaf\source>if exist bootstrap rd /S /Q bootstrap

C:\Users\Olaf\source>md bootstrap

C:\Users\Olaf\source>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/
/Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib
user32.lib /Febootstrap\yyacc0 yyacc.c
yyacc.c
c1: fatal error C1083: Cannot open source file: 'yyacc.c': No such
file or directory





--
Olaf

[Olaf van der Spek via Boost]

On Thu, Nov 16, 2017 at 11:39 AM, Daniel James via Boost
<bo...@lists.boost.org> wrote:

> As always, the release managers would appreciate it if you download
> the candidate of your choice and give building it a try. Please report
> both success and failure, and anything else that is noteworthy.

MSVC 15.5.0 preview 4:

1>Info: Boost.Config is older than your compiler version - probably
nothing bad will happen - but you may wish to look for an update Boost
version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress
this message.
1>c:\vc\boost\boost\asio\detail\type_traits.hpp(57): error C4996:
'std::result_of': warning STL4014: std::result_of and std::result_of_t
are deprecated in C++17. They are superseded by std::invoke_result and
std::invoke_result_t. You can define
_SILENCE_CXX17_RESULT_OF_DEPRECATION_WARNING or
_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have
received this warning.

1>c:\program files (x86)\microsoft visual
studio\preview\community\vc\tools\msvc\14.12.25827\include\type_traits(1807):
note: see declaration of 'std::result_of'
1>c:\vc\boost\boost\asio\associated_allocator.hpp(103): error C4996:
'std::allocator<void>': warning STL4009: std::allocator<void> is
deprecated in C++17. You can define
_SILENCE_CXX17_ALLOCATOR_VOID_DEPRECATION_WARNING or
_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have
received this warning.

1>c:\program files (x86)\microsoft visual
studio\preview\community\vc\tools\msvc\14.12.25827\include\xmemory0(1087):
note: see declaration of 'std::allocator<void>'
1>c:\vc\boost\boost\asio\use_future.hpp(130): error C4996:
'std::allocator<void>': warning STL4009: std::allocator<void> is
deprecated in C++17. You can define
_SILENCE_CXX17_ALLOCATOR_VOID_DEPRECATION_WARNING or
_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have
received this warning.

1>c:\program files (x86)\microsoft visual
studio\preview\community\vc\tools\msvc\14.12.25827\include\xmemory0(1087):
note: see declaration of 'std::allocator<void>'
1>Done building project "Polylines.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========



--
Olaf

[Marcel Raad via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Daniel
> James via Boost
> Sent: Donnerstag, 16. November 2017 11:39
> To: bo...@lists.boost.org
> Cc: Daniel James <dnl...@gmail.com>
> Subject: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1
>
> The release candidates for the 1.66.0 beta release are now available at:

> [...]

>
> As always, the release managers would appreciate it if you download
> the candidate of your choice and give building it a try. Please report
> both success and failure, and anything else that is noteworthy.

A first smoke test building one big project worked fine for me with VS 15.4.4.
Only the annoying errors because I forgot to delete %TEMP%\ b2_msvc_*.cmd again:
https://github.com/boostorg/build/issues/257

Marcel

[Olaf van der Spek via Boost]

On Thu, Nov 16, 2017 at 4:55 PM, Marcel Raad via Boost
<bo...@lists.boost.org> wrote:
> A first smoke test building one big project worked fine for me with VS 15.4.4.

Has 15.4.4 been released yet?
--
Olaf

[Marcel Raad via Boost]

> -----Original Message-----
> From: Olaf van der Spek [mailto:m...@vdspek.org]
> Sent: Donnerstag, 16. November 2017 17:06
> To: bo...@lists.boost.org
> Cc: Marcel Raad <Marce...@teamviewer.com>
> Subject: Re: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1
>
> On Thu, Nov 16, 2017 at 4:55 PM, Marcel Raad via Boost
> <bo...@lists.boost.org> wrote:
> > A first smoke test building one big project worked fine for me with VS
> 15.4.4.
>
> Has 15.4.4 been released yet?

Yes, I updated yesterday morning.

Marcel

[Stefan Seefeld via Boost]

On 16.11.2017 10:21, Daniel James via Boost wrote:
> On 16 November 2017 at 15:10, Peter Dimov via Boost
> <bo...@lists.boost.org> wrote:
>> Stefan Seefeld wrote:
>>> It looks like we falsely assume the compiler understands C++11 and thus
>>> use attempt to use std::integral_constant. Could it be that the conditional
>>> in
>>> https://github.com/boostorg/python/blob/develop/include/boost/python/detail/type_traits.hpp#L10-L11
>>> is wrong ?
>>
>> You should probably be checking BOOST_NO_CXX11_HDR_TYPE_TRAITS there unless
>> you have a specific reason not to do so.
> Yes, but I think the error is because it doesn't understand the C++11
> type alias. Better to use:
>
> typedef std::integral_constant<bool, true> true_;
> typedef std::integral_constant<bool, false> false_;
>
> According to MSDN, std::integral_constant was in Visual Studio 2008,
> which is Visual C++ 9.

OK, thanks. I have committed
https://github.com/boostorg/python/commit/b9d0d974995d2ed6a7aeed877ee4d8ab0a5b26cf
and will merge to master once the change cycles through a round of
tests. (I have to admit that I find it extremely daunting to navigate
the online test matrix. There are so many false positives that it's hard
to spot actual failures.)

Regards,

Stefan

--

...ich hab' noch einen Koffer in Berlin...

[Daniel James via Boost]

On 16 November 2017 at 16:16, Stefan Seefeld via Boost

<bo...@lists.boost.org> wrote:
>
> OK, thanks. I have committed
> https://github.com/boostorg/python/commit/b9d0d974995d2ed6a7aeed877ee4d8ab0a5b26cf
> and will merge to master once the change cycles through a round of
> tests. (I have to admit that I find it extremely daunting to navigate
> the online test matrix. There are so many false positives that it's hard
> to spot actual failures.)

Presumably a lot of those are due to python not being available or
properly set up, would it be possible to detect this in boost build?

[Stefan Seefeld via Boost]

On 16.11.2017 11:33, Daniel James via Boost wrote:
> On 16 November 2017 at 16:16, Stefan Seefeld via Boost
> <bo...@lists.boost.org> wrote:
>> OK, thanks. I have committed
>> https://github.com/boostorg/python/commit/b9d0d974995d2ed6a7aeed877ee4d8ab0a5b26cf
>> and will merge to master once the change cycles through a round of
>> tests. (I have to admit that I find it extremely daunting to navigate
>> the online test matrix. There are so many false positives that it's hard
>> to spot actual failures.)
> Presumably a lot of those are due to python not being available or
> properly set up, would it be possible to detect this in boost build?

Of course !
I agree, such situations should be flagged much earlier, and the
Boost.Python build (and tests) skipped. Sometime however the failure is
different, though, but with the same net effect: rendering the test
results useless as the failures don't tell anything about the code, but
rather the testing platform setup.

Stefan

--

...ich hab' noch einen Koffer in Berlin...

[Mikhail Strelnikov via Boost]

This is Microsoft's bug, they should not change current directory in
their vsdevcmd_end.bat.

https://github.com/boostorg/build/pull/252

[Marcel Raad via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Marcel
> Raad via Boost
> Sent: Donnerstag, 16. November 2017 16:55
> To: bo...@lists.boost.org
> Cc: Marcel Raad <Marce...@teamviewer.com>

> Subject: Re: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1
>
> A first smoke test building one big project worked fine for me with VS 15.4.4.

This project obviously didn't use Asio. There are breaking changes in the "Initial merge of Networking TS compatibility." commit, which should probably at least be mentioned in Asio's changelog? The changelog is older than that commit, unfortunately.

Also, ScopeExit still doesn't work with MSVC's /permissive- (ISO C++ compatibility mode), for which there is a PR:
https://github.com/boostorg/scope_exit/pull/3

[Vinnie Falco via Boost]

On Thu, Nov 16, 2017 at 1:42 PM, Marcel Raad via Boost
<bo...@lists.boost.org> wrote:
> There are breaking changes in the "Initial merge of Networking TS compatibility." commit

I updated Beast to use the "Net.TS-flavored Boost.Asio" (my name for
the new Boost.Asio implementation) do you have any specific questions
about the changes that I might be able to answer?

Thanks

[Marcel Raad via Boost]

Hi Vinnie,

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Vinnie
> Falco via Boost
> Sent: Donnerstag, 16. November 2017 23:04
> To: bo...@lists.boost.org
> Cc: Vinnie Falco <vinnie...@gmail.com>
> Subject: Re: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1
>

> On Thu, Nov 16, 2017 at 1:42 PM, Marcel Raad via Boost
> <bo...@lists.boost.org> wrote:
> > There are breaking changes in the "Initial merge of Networking TS
> compatibility." commit
>
> I updated Beast to use the "Net.TS-flavored Boost.Asio" (my name for
> the new Boost.Asio implementation) do you have any specific questions
> about the changes that I might be able to answer?

thanks for the offer! All issues are sorted out now:
- we were still using the deprecated asio::strand typedef as there were no warnings
- we were reyling on implicit io_service.hpp includes
- strand::wrap lost support for more than two function arguments as detail::binder[3..5] were removed. Chris Kohlhoff just responded to me privately that he'll add them back.

Thanks,
Marcel

[Daniel James via Boost]

On 16 November 2017 at 18:23, Mikhail Strelnikov via Boost

<bo...@lists.boost.org> wrote:
> This is Microsoft's bug, they should not change current directory in
> their vsdevcmd_end.bat.
>
> https://github.com/boostorg/build/pull/252

It looks like there's an incoming workaround:

https://github.com/boostorg/build/pull/263

I'd rather not delay this beta for this, as it's an issue with a
preview compiler, but hopefully it should be fixed soon.

[Daniel James via Boost]

On 16 November 2017 at 22:03, Vinnie Falco via Boost

<bo...@lists.boost.org> wrote:
> On Thu, Nov 16, 2017 at 1:42 PM, Marcel Raad via Boost
> <bo...@lists.boost.org> wrote:
>> There are breaking changes in the "Initial merge of Networking TS compatibility." commit
>
> I updated Beast to use the "Net.TS-flavored Boost.Asio" (my name for
> the new Boost.Asio implementation) do you have any specific questions
> about the changes that I might be able to answer?

It's be useful if someone wrote some release notes. It doesn't have to
be the maintainer.

[Olaf van der Spek via Boost]

On Fri, Nov 17, 2017 at 10:30 AM, Daniel James via Boost
<bo...@lists.boost.org> wrote:
> On 16 November 2017 at 18:23, Mikhail Strelnikov via Boost
> <bo...@lists.boost.org> wrote:
>> This is Microsoft's bug, they should not change current directory in
>> their vsdevcmd_end.bat.
>>
>> https://github.com/boostorg/build/pull/252
>
> It looks like there's an incoming workaround:
>
> https://github.com/boostorg/build/pull/263
>
> I'd rather not delay this beta for this, as it's an issue with a
> preview compiler, but hopefully it should be fixed soon.

15.4 is not preview..


--
Olaf

[Andrey Semashev via Boost]

On 11/17/17 12:50, Daniel James via Boost wrote:
> On 16 November 2017 at 22:03, Vinnie Falco via Boost
> <bo...@lists.boost.org> wrote:
>> On Thu, Nov 16, 2017 at 1:42 PM, Marcel Raad via Boost
>> <bo...@lists.boost.org> wrote:
>>> There are breaking changes in the "Initial merge of Networking TS compatibility." commit
>>
>> I updated Beast to use the "Net.TS-flavored Boost.Asio" (my name for
>> the new Boost.Asio implementation) do you have any specific questions
>> about the changes that I might be able to answer?
>
> It's be useful if someone wrote some release notes. It doesn't have to
> be the maintainer.

It looks like Boost.ASIO is based on some pre-release version of ASIO
1.11.0, which has release notes here:

http://think-async.com/asio/asio-1.11.0/doc/asio/history.html#asio.history.asio_1_11_0

Unfortunately, it looks like some of the new features are not available
in Boost.ASIO (e.g. I couldn't find address_cast<>). It looks like
Christopher is the only one who knows what changes went into Boost,
unless someone else follows the development closely.

I'm CCing Christopher in hope he will be able to provide some release
notes for Boost.ASIO. For convenience, the release notes can be provided
by creating a pull request for this file:

https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.qbk

Thanks.

[Vinnie Falco via Boost]

On Fri, Nov 17, 2017 at 2:38 AM, Andrey Semashev via Boost
<bo...@lists.boost.org> wrote:
> I'm CCing Christopher in hope he will be able to provide some release notes
> for Boost.ASIO.

Note that there are a growing number of issues and pull requests in
both of the asio repositories:
<https://github.com/boostorg/asio/issues>
<https://github.com/boostorg/asio/pulls>
<https://github.com/chriskohlhoff/asio/issues>
<https://github.com/chriskohlhoff/asio/pulls>

In some cases it is affecting the quality of the Boost library, for example:
<https://github.com/chriskohlhoff/asio/issues/246>

If there is anything that the rest of the Boost community can do to
assist with unblocking, I would like to know - I am willing to help.

Thanks

[Stefan Seefeld via Boost]

On 16.11.2017 11:16, Stefan Seefeld wrote:
> On 16.11.2017 10:21, Daniel James via Boost wrote:
>> On 16 November 2017 at 15:10, Peter Dimov via Boost
>> <bo...@lists.boost.org> wrote:
>>> Stefan Seefeld wrote:
>>>> It looks like we falsely assume the compiler understands C++11 and thus
>>>> use attempt to use std::integral_constant. Could it be that the conditional
>>>> in
>>>> https://github.com/boostorg/python/blob/develop/include/boost/python/detail/type_traits.hpp#L10-L11
>>>> is wrong ?
>>> You should probably be checking BOOST_NO_CXX11_HDR_TYPE_TRAITS there unless
>>> you have a specific reason not to do so.
>> Yes, but I think the error is because it doesn't understand the C++11
>> type alias. Better to use:
>>
>> typedef std::integral_constant<bool, true> true_;
>> typedef std::integral_constant<bool, false> false_;
>>
>> According to MSDN, std::integral_constant was in Visual Studio 2008,
>> which is Visual C++ 9.
>
> OK, thanks. I have committed
> https://github.com/boostorg/python/commit/b9d0d974995d2ed6a7aeed877ee4d8ab0a5b26cf
> and will merge to master once the change cycles through a round of
> tests. (I have to admit that I find it extremely daunting to navigate
> the online test matrix. There are so many false positives that it's
> hard to spot actual failures.)

So just for avoidance of doubt: at some point in the near future someone
will send out a note to the list that the `master` branch is open for
bug fixes, at which point this can be merged. Correct ?

Thanks,

[Daniel James via Boost]

On 17 November 2017 at 16:02, Stefan Seefeld via Boost

<bo...@lists.boost.org> wrote:
>
> So just for avoidance of doubt: at some point in the near future someone
> will send out a note to the list that the `master` branch is open for
> bug fixes, at which point this can be merged. Correct ?

Yes, once the beta is out, master will be open fixes. Although you can
merge this change now if you want, I'll include it if there's a second
release candidate for the beta, otherwise it will be picked up when
the commit bot is restarted on master.

[Tom Kent via Boost]

On Fri, Nov 17, 2017 at 1:25 PM, Daniel James via Boost <
bo...@lists.boost.org> wrote:

> On 17 November 2017 at 16:02, Stefan Seefeld via Boost
> <bo...@lists.boost.org> wrote:
> >
> > So just for avoidance of doubt: at some point in the near future someone
> > will send out a note to the list that the `master` branch is open for
> > bug fixes, at which point this can be merged. Correct ?
>
> Yes, once the beta is out, master will be open fixes. Although you can
> merge this change now if you want, I'll include it if there's a second
> release candidate for the beta, otherwise it will be picked up when
> the commit bot is restarted on master.

I had assumed that we were waiting for b1_rc2 for this fix, since it was
identified as a clear breakage for one of the supported compilers.
I'd personally like to see the releases (and also betas) at least build the
libraries that need to be built across the >=msvc-10.0 compilers.

Tom

[Daniel James via Boost]

On 17 November 2017 at 19:34, Tom Kent via Boost <bo...@lists.boost.org> wrote:
>
> I had assumed that we were waiting for b1_rc2 for this fix, since it was
> identified as a clear breakage for one of the supported compilers.
> I'd personally like to see the releases (and also betas) at least build the
> libraries that need to be built across the >=msvc-10.0 compilers.

I don't think we've ever stated such a requirement for betas, but I
don't know if there's going to be a second release candidate, I
haven't even discussed it with the other release managers yet.

[Tom Kent via Boost]

On Fri, Nov 17, 2017 at 4:56 PM, Daniel James via Boost <
bo...@lists.boost.org> wrote:

> On 17 November 2017 at 19:34, Tom Kent via Boost <bo...@lists.boost.org>
> wrote:
> >
> > I had assumed that we were waiting for b1_rc2 for this fix, since it was
> > identified as a clear breakage for one of the supported compilers.
> > I'd personally like to see the releases (and also betas) at least build
> the
> > libraries that need to be built across the >=msvc-10.0 compilers.
>
> I don't think we've ever stated such a requirement for betas, but I
> don't know if there's going to be a second release candidate, I
> haven't even discussed it with the other release managers yet.

I don't think there should be any stated requirement. I was just going with
what I've seen in the past as a rule of thumb plus my general desire.

Tom

[Vinnie Falco via Boost]

I just pushed a tiny fix to the beast master branch:

<https://github.com/boostorg/beast/commit/73eba08cf4029d63f7830d1adef9787b49bf50c5>

The bug is minor and likely will not be noticed so if this ends up
being delayed to 1.67.0 that is okay.

Thanks

[Daniel James via Boost]

On 19 November 2017 at 02:13, Vinnie Falco via Boost

<bo...@lists.boost.org> wrote:
> I just pushed a tiny fix to the beast master branch:
>
> <https://github.com/boostorg/beast/commit/73eba08cf4029d63f7830d1adef9787b49bf50c5>
>
> The bug is minor and likely will not be noticed so if this ends up
> being delayed to 1.67.0 that is okay.

You can fix bugs after the beta. But I'm making a second release
candidate with the python fix, I'll include this as well. It'll be
based on this commit:

https://github.com/boostorg/boost/commit/81dcc8faaafafaff16c9fd1f676ecd13b3f8dc23

Unless anyone sees anything wrong with that?

[Christopher Kohlhoff via Boost]

> On 17 Nov 2017, at 9:38 pm, Andrey Semashev <andrey....@gmail.com> wrote:
>
> I'm CCing Christopher in hope he will be able to provide some release notes for Boost.ASIO. For convenience, the release notes can be provided by creating a pull request for this file:
>
> https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.qbk

Based on the calendar (i.e. http://www.boost.org/development/index.html) I had set aside some time to prepare the release notes prior to the actual 1.66 release in December.

I have just now written some placeholder notes so that beta users will be aware that there have been some changes.

[Daniel James via Boost]

On 19 November 2017 at 23:54, Christopher Kohlhoff via Boost

<bo...@lists.boost.org> wrote:
>
>> On 17 Nov 2017, at 9:38 pm, Andrey Semashev <andrey....@gmail.com> wrote:
>>
>> I'm CCing Christopher in hope he will be able to provide some release notes for Boost.ASIO. For convenience, the release notes can be provided by creating a pull request for this file:
>>
>> https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.qbk
>
> Based on the calendar (i.e. http://www.boost.org/development/index.html) I had set aside some time to prepare the release notes prior to the actual 1.66 release in December.
>
> I have just now written some placeholder notes so that beta users will be aware that there have been some changes.

Thanks, it's useful to have something in the beta so that people can
tell if what they needs to tested, and whether the release will affect
them.

[Andrey Semashev via Boost]

On 11/20/17 02:54, Christopher Kohlhoff wrote:
>
>> On 17 Nov 2017, at 9:38 pm, Andrey Semashev <andrey....@gmail.com> wrote:
>>
>> I'm CCing Christopher in hope he will be able to provide some release notes for Boost.ASIO. For convenience, the release notes can be provided by creating a pull request for this file:
>>
>> https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.qbk
>
> Based on the calendar (i.e. http://www.boost.org/development/index.html) I had set aside some time to prepare the release notes prior to the actual 1.66 release in December.
>
> I have just now written some placeholder notes so that beta users will be aware that there have been some changes.

Just a friendly reminder that the 1.66 release is near and the list of
changes is still TBD.

[Stefan Seefeld via Boost]

Hello,

I'd like to report again an issue with the Windows binary packages that
is still present with the 1.66.0 release (candidate). The issue is
reported to the Boost.Python bug tracker at
https://github.com/boostorg/python/issues/129, though I don't think I
can address it there.
In the Windows binary package the libboost_python3 library is built
against (and links with) python2. I can't reproduce this myself when
building Boost the normal way, and I don't know who owns the logic for
building Windows binary packages. It doesn't seem to have its own repo /
issue tracker.
The fix might thus affect some piece of code that isn't itself part of
the release. But it would be great if someone could look into it soon
anyhow. :-)

Regards,

Stefan

--

...ich hab' noch einen Koffer in Berlin...

[Tom Kent via Boost]

On Fri, Dec 8, 2017 at 6:10 AM, Stefan Seefeld via Boost <
bo...@lists.boost.org> wrote:

> Hello,
>
> I'd like to report again an issue with the Windows binary packages that
> is still present with the 1.66.0 release (candidate). The issue is
> reported to the Boost.Python bug tracker at
> https://github.com/boostorg/python/issues/129, though I don't think I
> can address it there.
> In the Windows binary package the libboost_python3 library is built
> against (and links with) python2. I can't reproduce this myself when
> building Boost the normal way, and I don't know who owns the logic for
> building Windows binary packages. It doesn't seem to have its own repo /
> issue tracker.
> The fix might thus affect some piece of code that isn't itself part of
> the release. But it would be great if someone could look into it soon
> anyhow. :-)
>

I've got the logic for the windows builds here:
https://github.com/teeks99/boost-release-windows/

I'm baffled by why this is happening. I'm including both python 2 and 3
paths in user-config.jam:
https://github.com/teeks99/boost-release-windows/blob/master/user-config.jam.template

Is there anything else I should be doing for the python build?

Tom

[Stefan Seefeld via Boost]

I managed to reproduce the problem on Linux (not quite the same, as on
Linux Boost.Python isn't linked to the Python library, but the problem
is there nonetheless).
I reported my findings to
https://lists.boost.org/boost-build/2017/12/29715.php.
In a nutshell, the problem is that the Boost.Build logic doesn't create
a build tree layout that contains the Python version as a path
component. As a consequence, it mistakenly reuses object files compiled
with the previous Python version when linking Boost.Python libraries for
subsequent Python versions.

The real fix (arguably to Boost.Build) is quite involved, and may be too
late for the upcoming release. It might be better to consider changing
the build script to invoke `b2` multiple times (once per Python
version), and then package the libraries together, so the end result
will look the same.

Stefan

--

...ich hab' noch einen Koffer in Berlin...

[Tom Kent via Boost]

On Fri, Dec 8, 2017 at 8:28 AM, Stefan Seefeld via Boost <

That sounds tricky.

Does that mean that I'd need to modify my user-config.jam file between the
two builds? (I.e. only have one version of python in there at a time?)

I'm not sure I have the time to put in script changes for this before the
next release. Instead, I think I'll just disable python3 (i.e. remove it
from user-config.jam) so the windows build will only support python2. It is
kinda a toss-up as to py2 vs. py3, the python community is definitely
shifting away from py2 (end of life in 2020), but if there are users who
have been building with the windows builds in the past, it was only working
for py2 so I don't want to break that.

Tom

[Stefan Seefeld via Boost]

I believe so, yes (though would prefer someone like Steven or Rene as
the real experts to confirm the whole issue, as I may miss something).

> I'm not sure I have the time to put in script changes for this before the
> next release. Instead, I think I'll just disable python3 (i.e. remove it
> from user-config.jam) so the windows build will only support python2. It is
> kinda a toss-up as to py2 vs. py3, the python community is definitely
> shifting away from py2 (end of life in 2020), but if there are users who
> have been building with the windows builds in the past, it was only working
> for py2 so I don't want to break that.

Right, I agree with that assessment & strategy.

Stefan

--

...ich hab' noch einen Koffer in Berlin...

[Steven Watanabe via Boost]

AMDG

On 12/08/2017 07:36 PM, Stefan Seefeld via Boost wrote:
> On 08.12.2017 21:32, Tom Kent via Boost wrote:
>>
>> That sounds tricky.
>>
>> Does that mean that I'd need to modify my user-config.jam file between the
>> two builds? (I.e. only have one version of python in there at a time?)
>
> I believe so, yes (though would prefer someone like Steven or Rene as
> the real experts to confirm the whole issue, as I may miss something).
>

I'm not really familiar with the python toolset,
but user-config.jam can contain arbitrary code,
so, if there isn't a better solution, you can
fall back on something like this:

# Adjust the build paths when python3 is in use.
# Note: This applies to all targets, even those
# unrelated to python, so it's probably a bad idea
# to use the --use-python3 option for building anything
# other than Boost.Python.
import feature ;
feature.feature python-version : 3 : propagated optional ;

import modules ;
import toolset ;
# Allow command line switching
if --use-python3 in [ modules.peek : ARGV ]
{
project : requirements <python-version>3 ;
using python : 3.xx : ... ;
}
else
{
using python : 2.xx : ... ;
}

In Christ,
Steven Watanabe

[Stefan Seefeld via Boost]

Hi Steven,

Can you elaborate a bit on what this will achieve ? It seems this simply
means the same user-config.jam file can be reused for two `b2`
invocations (one with `--use-python3` and one without). But the build
logic would still need to be augmented to:

1) run `b2` as before
2) remove the build tree for Boost.Python, i.e. everything under
`bin.v2/libs/python`
3) rerun `b2`, this time with additional `--use-python3 --with-python`
arguments, to only rebuild Boost.Python, this time with Python3.
4) collect all binaries from the staging area during packaging.

Correct ?

Thanks,

Stefan

--

...ich hab' noch einen Koffer in Berlin...

[Steven Watanabe via Boost]

AMDG

On 12/08/2017 08:00 PM, Stefan Seefeld via Boost wrote:
> On 08.12.2017 21:52, Steven Watanabe via Boost wrote:

>> <snip>

>> import feature ;
>> feature.feature python-version : 3 : propagated optional ;
>>
>> import modules ;
>> import toolset ;
>> # Allow command line switching
>> if --use-python3 in [ modules.peek : ARGV ]
>> {
>> project : requirements <python-version>3 ;
>> using python : 3.xx : ... ;
>> }
>> else
>> {
>> using python : 2.xx : ... ;
>> }
>
> Can you elaborate a bit on what this will achieve ? It seems this simply
> means the same user-config.jam file can be reused for two `b2`
> invocations (one with `--use-python3` and one without). But the build
> logic would still need to be augmented to:
>
> 1) run `b2` as before
> 2) remove the build tree for Boost.Python, i.e. everything under
> `bin.v2/libs/python`
> 3) rerun `b2`, this time with additional `--use-python3 --with-python`
> arguments, to only rebuild Boost.Python, this time with Python3.
> 4) collect all binaries from the staging area during packaging.
>
> Correct ?
>

Step (2) is not necessary. python-version is specifically
to avoid this step, by forcing the python3 build to
use a different build directory.

In Christ,
Steven Watanabe

[Stefan Seefeld via Boost]

I see, thanks. What would be the "correct" fix for this, i.e. where
would this `python-version` feature have to be defined (and used) to
allow `b2` to be usable as intended, i.e. building for both, Python2 and
Python3 in a single run ?
(I take it even with this it would still not be possible to build
against two arbitrary Python versions, as the feature as it is defined
now will only distinguish between '2' and '3', rather than taking the
exact Python version into account, as it does for toolchain versions.)

Stefan

--

...ich hab' noch einen Koffer in Berlin...

[Steven Watanabe via Boost]

AMDG

On 12/08/2017 08:18 PM, Stefan Seefeld via Boost wrote:
>
> I see, thanks. What would be the "correct" fix for this, i.e. where
> would this `python-version` feature have to be defined (and used) to
> allow `b2` to be usable as intended, i.e. building for both, Python2 and
> Python3 in a single run ?

The right place is either build/src/tools/python.jam
or the Boost.Python Jamfile. Hmm. It looks like there's
already code to handle this (<python>). I wonder why
it doesn't work.

> (I take it even with this it would still not be possible to build
> against two arbitrary Python versions, as the feature as it is defined
> now will only distinguish between '2' and '3', rather than taking the
> exact Python version into account, as it does for toolchain versions.)
>

This is just a quick hack. The version could be
any string. The library names also need to be
mangled. If I remember correctly, the current
Jamfile only distinguishes boost_python and boost_python3.

In Christ,
Steven Watanabe

[Stefan Seefeld via Boost]

On 08.12.2017 22:40, Steven Watanabe via Boost wrote:
> AMDG
>
> On 12/08/2017 08:18 PM, Stefan Seefeld via Boost wrote:
>> I see, thanks. What would be the "correct" fix for this, i.e. where
>> would this `python-version` feature have to be defined (and used) to
>> allow `b2` to be usable as intended, i.e. building for both, Python2 and
>> Python3 in a single run ?
> The right place is either build/src/tools/python.jam
> or the Boost.Python Jamfile. Hmm. It looks like there's
> already code to handle this (<python>). I wonder why
> it doesn't work.

I have submitted https://github.com/boostorg/build/issues/271 for this.

Thanks,

Stefan

--

...ich hab' noch einen Koffer in Berlin...