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

[Daniel James via Boost]

The release candidates for the first 1.67.0 beta release are now available at:

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

The release notes can be previewed at:

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

The documentation is available at:

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

The SHA256 checksums are as follows:

3d52af11ea6c45c73e18bf9b386056d31dab5092923cc9ed8efa29a083ffb9de
boost_1_67_0_b1_rc1.7z
680336bd9a56dccda359061660348c5656cab71cb76713b157ce9a6f840659f0
boost_1_67_0_b1_rc1.tar.bz2
a4608b3ee0b4fadad7b2a2a9efa7c4ad8ce120ee94232e0ee86796f38cced319
boost_1_67_0_b1_rc1.tar.gz
3d1faa96ddda6f0a864f3292c014420457159f0960ff82efcca9feb898d21c1a
boost_1_67_0_b1_rc1.zip

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

[Lorenzo Caminiti via Boost]

Hello Daniel and all,

On Sat, Mar 10, 2018 at 11:57 AM, Daniel James via Boost
<bo...@lists.boost.org> wrote:
> The release candidates for the first 1.67.0 beta release are now available at:
> <https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/source/>

I downloaded the .7z release candidate and I was able to build it. I
used GCC 6.4.0 on Cygwin.

I noticed the following couple of Jamfile warnings (maybe they can be
ignored...):
$ ./b2
../../../libs/log/build/Jamfile.v2:45: Unescaped special character in
argument <define>$(flag)=1
../../../libs/python/Jamfile:49: Unescaped special character in
argument [*\/:."']
/home/310206419/tmp/boost_1_67_0_b1_rc1/boost_1_67_0/libs/predef/check/../tools/check/predef.jam:46:
Unescaped special character in argument $(language)::$(expression)

I also built and run all Boost.Contract examples and tests, no problem.

> The release notes can be previewed at:
> <http://www.boost.org/users/history/in_progress.html>

Release notes for Boost.Contract look good.

> The documentation is available at:
> <http://www.boost.org/doc/libs/1_67_0_beta1/>

Boost.Contract doc looks good.

Thank you.
--Lorenzo

[Andrzej Krzemienski via Boost]

Tried to build on Fedora 27, GCC 7.3.1. With command`./b2
--prefix=./Install toolset=gcc stage`

Libraries and shared objects do get built, I get a number of errors about
missing file <pyconfig.h>, e.g.:

```
In file included from ./boost/python/detail/prefix.hpp:13:0,
from ./boost/python/list.hpp:8,
from libs/python/src/list.cpp:5:
./boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No
such file or directory
# include <pyconfig.h>
^~~~~~~~~~~~
compilation terminated.

"g++" -m64 -pthread -O3 -finline-functions -Wno-inline -Wall
-DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB
-DNDEBUG -I"." -I"/usr/include/python2.7" -c -o
"bin.v2/libs/python/build/gcc-7.3.1/release/link-static/threading-multi/list.o"
"libs/python/src/list.cpp"
```

The entire output is in attachment `gcc.output`.

Regards,
&rzej;

[Olaf van der Spek via Boost]

On Sat, Mar 10, 2018 at 8:57 PM, 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.

Windows 7 x64; MSVC 15.6.1; normal cmd prompt:

C:\VC\boost>b2
libs\log\build\Jamfile.v2:45: Unescaped special character in argument
<define>$(flag)=1
libs\python\Jamfile:49: Unescaped special character in argument [*\/:."']
C:/VC/boost/libs/predef/check/../tools/check\predef.jam:46: Unescaped

special character in argument $(language)::$(expression)

Performing configuration checks

- default address-model : 32-bit
- default architecture : x86

Building the Boost C++ Libraries.


- symlinks supported : yes
- C++11 mutex : yes
- Boost.Config Feature Check: cxx11_auto_declarations : yes
- Boost.Config Feature Check: cxx11_constexpr : yes
- Boost.Config Feature Check: cxx11_defaulted_functions : yes
- Boost.Config Feature Check: cxx11_final : yes
- Boost.Config Feature Check: cxx11_hdr_mutex : yes
- Boost.Config Feature Check: cxx11_hdr_regex : yes
- Boost.Config Feature Check: cxx11_hdr_tuple : yes
- Boost.Config Feature Check: cxx11_lambdas : yes
- Boost.Config Feature Check: cxx11_noexcept : yes
- Boost.Config Feature Check: cxx11_nullptr : yes
- Boost.Config Feature Check: cxx11_rvalue_references : yes
- Boost.Config Feature Check: cxx11_template_aliases : yes
- Boost.Config Feature Check: cxx11_thread_local : yes
- Boost.Config Feature Check: cxx11_variadic_templates : yes
- has_icu builds : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam
- zlib : no
- bzip2 : no
- lzma : no
- iconv (libc) : no
- iconv (separate) : no
- icu : no
- icu (lib64) : no
- native-atomic-int32-supported : yes
- message-compiler : yes
- native-syslog-supported : no
- pthread-supports-robust-mutexes : no
- compiler-supports-visibility : no
- compiler-supports-ssse3 : yes
- compiler-supports-avx2 : yes
- gcc visibility : no
- long double support : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
warning: No python installation configured and autoconfiguration
note: failed. See http://www.boost.org/libs/python/doc/building.html
note: for configuration instructions or pass --without-python to
note: suppress this message and silently skip all Boost.Python targets
error: at C:/VC/boost/tools/build/src/kernel\modules.jam:107
error: Unable to find file or target named
error: 'python_for_extensions'
error: referred to from project at
error: ''

> --without-python

Is Python enabled by default?



--
Olaf

[Daniel James via Boost]

On 11 March 2018 at 09:08, Olaf van der Spek <m...@vdspek.org> wrote:
> error: Unable to find file or target named
> error: 'python_for_extensions'
> error: referred to from project at
> error: ''
>
>> --without-python
>
> Is Python enabled by default?

According to git bisect, this error was caused by:

https://github.com/boostorg/python/commit/d4d41d94aecc9f8098aabd3587fcb95458451f71

I think the best thing to do is revert that commit, or maybe the
recent changes to python.

[Tom Kent via Boost]

On Sat, Mar 10, 2018 at 1:57 PM, Daniel James via Boost <
bo...@lists.boost.org> wrote:

> The release candidates for the first 1.67.0 beta release are now available
> at:
>
> <https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/source/>
>
> The release notes can be previewed at:
>
> <http://www.boost.org/users/history/in_progress.html>
>
> The documentation is available at:
>
> <http://www.boost.org/doc/libs/1_67_0_beta1/>
>
> The SHA256 checksums are as follows:
>
> 3d52af11ea6c45c73e18bf9b386056d31dab5092923cc9ed8efa29a083ffb9de
> boost_1_67_0_b1_rc1.7z
> 680336bd9a56dccda359061660348c5656cab71cb76713b157ce9a6f840659f0
> boost_1_67_0_b1_rc1.tar.bz2
> a4608b3ee0b4fadad7b2a2a9efa7c4ad8ce120ee94232e0ee86796f38cced319
> boost_1_67_0_b1_rc1.tar.gz
> 3d1faa96ddda6f0a864f3292c014420457159f0960ff82efcca9feb898d21c1a
> boost_1_67_0_b1_rc1.zip
>
> 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 got a huge number of Build errors for msvc-8.0 through msvc-12.0, all in
the context library.

For msvc-8.0 and msvc-9.0 this is because of a failure to find cstdint
(which isn't in those compilers).
https://gist.github.com/teeks99/7093222f2dce67de18cf940fddea088c#file-boost_1_67_0_b1_rc1-32bitlog-txt-L95


For msvc-10.0, 11.0, and 12.0, there are a slew of arcane syntax errors:
https://gist.github.com/teeks99/7093222f2dce67de18cf940fddea088c#file-boost_1_67_0_b1_rc1-32bitlog-txt-L427

After looking at the context documentation for a bit, I finally noticed a
tiny note (
http://www.boost.org/doc/libs/1_67_0_beta1/libs/context/doc/html/context/overview.html)
(not
on the "requirements" page!) that specified this is a C++11 library. Fine,
then it needs to not build when we run an earlier compiler against it. Did
something change from 1.66? This wasn't an issue then.
It also seems like minimum compiler requirements should be on the context
requirements page, for 99% of use cases msvc-12.0 is c++11 compliant, but
apparently not good enough for this library. I just added a github issue
for context to fix this https://github.com/boostorg/context/issues/74.

I think this beta should be blocked until the build is fixed so context
isn't being built by incompatible compilers, there are simply too many
errors output.

Everything else looked good.

Tom

toolset arch compile Link Execute
msvc-8.0 32 error X X
msvc-8.0 64 error X X
msvc-9.0 32 error X X
msvc-9.0 64 error X X
msvc-10.0 32 error X X
msvc-10.0 64 error X X
msvc-11.0 32 error X X
msvc-11.0 64 error X X
msvc-12.0 32 error X X
msvc-12.0 64 error 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.

[Stefan Seefeld via Boost]

Hi,

I wonder whether anyone from the Boost.Build project would be able to
comment, and can explain the error message.
It's true I relatively recently added
https://github.com/boostorg/python/commit/d4d41d94aecc9f8098aabd3587fcb95458451f71,
but I don't see how this could cause the observed error (which doesn't
seem to be about a failed Python detection, but about an internal
Boost.Build error (to detect the `python.python_for_extensions` rule).

I can't reproduce the problem myself. From the generated output it seems
as if passing `--without-python` would suppress the failure, but that
hadn't been necessary before, or has it ?

Thanks,

Stefan

--

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

[Daniel James via Boost]

On 11 March 2018 at 12:39, Tom Kent via Boost <bo...@lists.boost.org> wrote:
>
> I got a huge number of Build errors for msvc-8.0 through msvc-12.0, all in
> the context library.

It isn't good that we only find these errors in release candidates. Is
it possible for the testers to do a binary build before running the
tests? The test system doesn't catch these errors as the tests only
run for compilers with the necessary C++11 features.

> Did
> something change from 1.66? This wasn't an issue then.

It looks like execution_context used to have checks for
BOOST_CONTEXT_NO_CXX11, but they were removed. So it would build okay
without C++11, but I'm not sure why that would be needed. Could the
build Jamfile have the same C++11 checks as the tests?

> I think this beta should be blocked until the build is fixed so context
> isn't being built by incompatible compilers, there are simply too many
> errors output.

It's already blocked by the python build error.

[Daniel James via Boost]

On 11 March 2018 at 13:27, Stefan Seefeld via Boost

<bo...@lists.boost.org> wrote:
>
> I wonder whether anyone from the Boost.Build project would be able to
> comment, and can explain the error message.
> It's true I relatively recently added
> https://github.com/boostorg/python/commit/d4d41d94aecc9f8098aabd3587fcb95458451f71,
> but I don't see how this could cause the observed error (which doesn't
> seem to be about a failed Python detection, but about an internal
> Boost.Build error (to detect the `python.python_for_extensions` rule).
>
> I can't reproduce the problem myself. From the generated output it seems
> as if passing `--without-python` would suppress the failure, but that
> hadn't been necessary before, or has it ?

If it wasn't clear, I found that commit by moving python to a
different directory so that boost build wouldn't find it, then running
the build with different versions of the boost python module. Before
the commit there would be a warning about python, but no error. After
that commit the build would fail with an error.

My guess is that 'python_for_extensions' is only defined when python
is installed, and the old 'rule lib_boost_python ( version )' would
only process its requirements as needed, if python wasn't installed,
the build would be cancelled and it wouldn't be run. But perhaps the
requirements for 'lib boost_python' are always processed, whether or
not python is installed.

[Peter Dimov via Boost]

Daniel James wrote:
> On 11 March 2018 at 12:39, Tom Kent via Boost <bo...@lists.boost.org>
> wrote:
> >
> > I got a huge number of Build errors for msvc-8.0 through msvc-12.0, all
> > in the context library.
>
> It isn't good that we only find these errors in release candidates. Is it
> possible for the testers to do a binary build before running the tests?

That's what check_build does:

http://www.boost.org/development/tests/master/developer/check_build.html

[Stefan Seefeld via Boost]

Oh. In that case
https://github.com/boostorg/python/commit/0021720a464742aec04b996e55c7f04560d6dad1
may be the solution ?

Stefan

--

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

[Oliver Kowalke via Boost]

unit-tests from boost.context test for features:

cxx11_auto_declarations
cxx11_constexpr
cxx11_defaulted_functions
cxx11_final
cxx11_hdr_thread
cxx11_hdr_tuple
cxx11_lambdas
cxx11_noexcept
cxx11_nullptr
cxx11_rvalue_references
cxx11_template_aliases
cxx11_thread_local
cxx11_variadic_templates

The host teeks99-08-e-win2012R2-64on64 running msvc-12.0 detects that msvc-12.0
is not compliant.

teeks99-08-m-win2012R2-32on64 fails because of the `context -
__boost_check_library__` - step but no information why it fails is provided

[Oliver Kowalke via Boost]

2018-03-11 14:50 GMT+01:00 Daniel James via Boost <bo...@lists.boost.org>:

> On 11 March 2018 at 12:39, Tom Kent via Boost <bo...@lists.boost.org>
> wrote:
> >
> > I got a huge number of Build errors for msvc-8.0 through msvc-12.0, all
> in
> > the context library.
>
> It isn't good that we only find these errors in release candidates. Is
> it possible for the testers to do a binary build before running the
> tests? The test system doesn't catch these errors as the tests only
> run for compilers with the necessary C++11 features.
>

msvc-7 + msvc+8 are excluded from building boost.context
the unit-tests are OK, msvc-12 does not compile .... the exception is
teeks99-08-m-win2012R2-32on64 where the check-library fails at runtime

>
> > Did
> > something change from 1.66? This wasn't an issue then.
>
> It looks like execution_context used to have checks for
> BOOST_CONTEXT_NO_CXX11, but they were removed. So it would build okay
> without C++11, but I'm not sure why that would be needed.
>

BOOST_CONTEXT_NO_CXX11 is only for supporting boost.coroutine

[Daniel James via Boost]

On 11 March 2018 at 14:14, Peter Dimov via Boost <bo...@lists.boost.org> wrote:
> Daniel James wrote:
>>
>> On 11 March 2018 at 12:39, Tom Kent via Boost <bo...@lists.boost.org>
>> wrote:
>> >
>> > I got a huge number of Build errors for msvc-8.0 through msvc-12.0, all
>> > > in the context library.
>>
>> It isn't good that we only find these errors in release candidates. Is it
>> possible for the testers to do a binary build before running the tests?
>
>
> That's what check_build does:
>
> http://www.boost.org/development/tests/master/developer/check_build.html

That's useful, although perhaps a bit obscure. Ideally we want to
build the libraries exactly as the user does. If there's a problem
with the super project's jamfiles would that catch it?

[Daniel James via Boost]

On 11 March 2018 at 14:52, Oliver Kowalke via Boost

<bo...@lists.boost.org> wrote:
> unit-tests from boost.context test for features:

This is building the binaries from the root directory, not running
unit tests, the unit test requirements won't be used.

[Peter Dimov via Boost]

Daniel James wrote:
> >> It isn't good that we only find these errors in release candidates. Is
> >> it possible for the testers to do a binary build before running the
> >> tests?
> >
> >
> > That's what check_build does:
> >
> > http://www.boost.org/development/tests/master/developer/check_build.html
>
> That's useful, although perhaps a bit obscure. Ideally we want to build
> the libraries exactly as the user does. If there's a problem with the
> super project's jamfiles would that catch it?

No, it wouldn't. We do have a Travis job that builds the libraries exactly
as the user does, but that's only for one specific configuration
(gcc/cxxstd=11). So if the superproject Jamfiles are broken on f.ex.
msvc-12.0, none of these will catch it. It's still better than nothing
though.

[Vinnie Falco via Boost]

On Sat, Mar 10, 2018 at 11:57 AM, Daniel James via Boost
<bo...@lists.boost.org> wrote:
> The release candidates for the first 1.67.0 beta release are now available...

Beast version 164 contains a critical bug fix that has to go in. I'm
re-running the Autobahn|Testsuite against it, which takes quite a
while. After it is done I will merge it, sorry for the extra work:

<https://github.com/boostorg/beast/pull/1063>

Thanks

[Steven Watanabe via Boost]

AMDG

On 03/11/2018 07:27 AM, Stefan Seefeld wrote:
> Hi,
>
> I wonder whether anyone from the Boost.Build project would be able to
> comment, and can explain the error message.
> It's true I relatively recently added
> https://github.com/boostorg/python/commit/d4d41d94aecc9f8098aabd3587fcb95458451f71,
> but I don't see how this could cause the observed error

I believe that this actually exposed a problem that
already existed rather than directly causing the problem.

> (which doesn't
> seem to be about a failed Python detection, but about an internal
> Boost.Build error (to detect the `python.python_for_extensions` rule).
>

I fixed this in
https://github.com/boostorg/build/commit/0dacbc3df69fbbb443f1ecaa0ee57c0157d47843
but it didn't get merged to the release branch
yet.

> I can't reproduce the problem myself. From the generated output it seems
> as if passing `--without-python` would suppress the failure, but that
> hadn't been necessary before, or has it ?
>

> <snip>

>> error: Unable to find file or target named
>> error: 'python_for_extensions'
>> error: referred to from project at
>> error: ''
>>
>>> --without-python
>> Is Python enabled by default?
>>
>>

In Christ,
Steven Watanabe

[Daniel James via Boost]

On 10 March 2018 at 23:41, Andrzej Krzemienski <akrz...@gmail.com> wrote:
> Tried to build on Fedora 27, GCC 7.3.1. With command`./b2 --prefix=./Install
> toolset=gcc stage`
>
> Libraries and shared objects do get built, I get a number of errors about
> missing file <pyconfig.h>, e.g.:
>
> ```
> In file included from ./boost/python/detail/prefix.hpp:13:0,
> from ./boost/python/list.hpp:8,
> from libs/python/src/list.cpp:5:
> ./boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No
> such file or directory
> # include <pyconfig.h>
> ^~~~~~~~~~~~
> compilation terminated.

I think this happens when you have python installed, but not
python-devel. So the build system finds python and tried to build
using it, but the headers are missing because python-devel isn't
installed. I'm not sure if build is meant to be able to detect this.

[Gavin Lambert via Boost]

On 12/03/2018 11:17, Daniel James wrote:
> On 10 March 2018 at 23:41, Andrzej Krzemienski <akrz...@gmail.com> wrote:
>> Tried to build on Fedora 27, GCC 7.3.1. With command`./b2 --prefix=./Install
>> toolset=gcc stage`
>>
>> Libraries and shared objects do get built, I get a number of errors about
>> missing file <pyconfig.h>, e.g.:
>>
>> ```
>> In file included from ./boost/python/detail/prefix.hpp:13:0,
>> from ./boost/python/list.hpp:8,
>> from libs/python/src/list.cpp:5:
>> ./boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No
>> such file or directory
>> # include <pyconfig.h>
>> ^~~~~~~~~~~~
>> compilation terminated.
>
> I think this happens when you have python installed, but not
> python-devel. So the build system finds python and tried to build
> using it, but the headers are missing because python-devel isn't
> installed. I'm not sure if build is meant to be able to detect this.

It would be nice if it did, but historically it hasn't. I've usually
just gotten into the habit of adding --without-python explicitly.

[Daniel James via Boost]

On 11 March 2018 at 18:10, Steven Watanabe via Boost

<bo...@lists.boost.org> wrote:
>
> I fixed this in
> https://github.com/boostorg/build/commit/0dacbc3df69fbbb443f1ecaa0ee57c0157d47843
> but it didn't get merged to the release branch
> yet.

OK, so shall we include that in the beta, and revert the fix in python?

[Stefan Seefeld via Boost]

On 12.03.2018 06:45, Daniel James via Boost wrote:
> On 11 March 2018 at 18:10, Steven Watanabe via Boost
> <bo...@lists.boost.org> wrote:
>> I fixed this in
>> https://github.com/boostorg/build/commit/0dacbc3df69fbbb443f1ecaa0ee57c0157d47843
>> but it didn't get merged to the release branch
>> yet.
> OK, so shall we include that in the beta, and revert the fix in python?

It might be worthwhile just merging the Boost.Build fix for now, without
merging anything in Boost.Python, as a minimal change to fix the issue.

There are actually two related commits in Python, one about
conditionalizing the main targets, the other about tests:

https://github.com/boostorg/python/commit/0021720a464742aec04b996e55c7f04560d6dad1
https://github.com/boostorg/python/commit/6b8ab7a5a3f0ef263055cb2a4b745d1304f0b528

I wouldn't mind keeping both, if only for clarity, but we can keep them
on the develop branch for now if they aren't considered release-critical.

Thanks,

Stefan

--

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

[Daniel James via Boost]

On 10 March 2018 at 19:57, Daniel James <dnl...@gmail.com> wrote:
> The release candidates for the first 1.67.0 beta release are now available at:

Just a quick update. All the blocking issues should be fixed in
develop now. Before release candidate 2 we need to merge changes from
beast, context and build to master, but I want to wait a couple of
days to let the test runners cycle before merging them. 1.67.0 beta1
rc2 should be ready later this week, and if all goes well, can release
the beta early next week.

If anyone else wants to include anything in the beta, please let me
know, but it's probably best to wait until after it is out.

Thanks to everyone who has worked on fixing the blocking issues.

[Daniel James via Boost]

On 12 March 2018 at 11:21, Stefan Seefeld via Boost

<bo...@lists.boost.org> wrote:
>
> It might be worthwhile just merging the Boost.Build fix for now, without
> merging anything in Boost.Python, as a minimal change to fix the issue.

Steven, is it okay to merge build to master?

[Tom Kent via Boost]

On Mon, Mar 12, 2018 at 8:36 AM, Daniel James via Boost <
bo...@lists.boost.org> wrote:

> On 10 March 2018 at 19:57, Daniel James <dnl...@gmail.com> wrote:
> > The release candidates for the first 1.67.0 beta release are now
> available at:
>
> Just a quick update. All the blocking issues should be fixed in
> develop now. Before release candidate 2 we need to merge changes from
> beast, context and build to master, but I want to wait a couple of
> days to let the test runners cycle before merging them. 1.67.0 beta1
> rc2 should be ready later this week, and if all goes well, can release
> the beta early next week.
>

I just tried building the latest snapshot from master (
https://dl.bintray.com/boostorg/master/boost_1_67_0-snapshot.tar.bz2),
listed as being packaged March 12. It still had the context build errors
for msvc-8.0 through msvc-12.0.

Tom

[Daniel James via Boost]

On 14 March 2018 at 13:30, Tom Kent via Boost <bo...@lists.boost.org> wrote:
> On Mon, Mar 12, 2018 at 8:36 AM, Daniel James via Boost <
> bo...@lists.boost.org> wrote:
>
>> On 10 March 2018 at 19:57, Daniel James <dnl...@gmail.com> wrote:
>> > The release candidates for the first 1.67.0 beta release are now
>> available at:
>>
>> Just a quick update. All the blocking issues should be fixed in
>> develop now. Before release candidate 2 we need to merge changes from
>> beast, context and build to master, but I want to wait a couple of
>> days to let the test runners cycle before merging them. 1.67.0 beta1
>> rc2 should be ready later this week, and if all goes well, can release
>> the beta early next week.
>>
>
> I just tried building the latest snapshot from master (
> https://dl.bintray.com/boostorg/master/boost_1_67_0-snapshot.tar.bz2),
> listed as being packaged March 12. It still had the context build errors
> for msvc-8.0 through msvc-12.0.

The fixes are in develop.

[Tom Kent via Boost]

On Wed, Mar 14, 2018 at 8:33 AM, Daniel James via Boost <

bo...@lists.boost.org> wrote:

> On 14 March 2018 at 13:30, Tom Kent via Boost <bo...@lists.boost.org>
> wrote:
> > On Mon, Mar 12, 2018 at 8:36 AM, Daniel James via Boost <
> > bo...@lists.boost.org> wrote:
> >
> >> On 10 March 2018 at 19:57, Daniel James <dnl...@gmail.com> wrote:
> >> > The release candidates for the first 1.67.0 beta release are now
> >> available at:
> >>
> >> Just a quick update. All the blocking issues should be fixed in
> >> develop now. Before release candidate 2 we need to merge changes from
> >> beast, context and build to master, but I want to wait a couple of
> >> days to let the test runners cycle before merging them. 1.67.0 beta1
> >> rc2 should be ready later this week, and if all goes well, can release
> >> the beta early next week.
> >>
> >
> > I just tried building the latest snapshot from master (
> > https://dl.bintray.com/boostorg/master/boost_1_67_0-snapshot.tar.bz2),
> > listed as being packaged March 12. It still had the context build errors
> > for msvc-8.0 through msvc-12.0.
>
> The fixes are in develop.

My mistake, I didn't read that correctly.

Once they are merged, are they going to cycle a bit more or is the next RC
going to be cut immediately?
Tom

[Daniel James via Boost]

I'll probably publish it tomorrow, but will also keep an eye on the
test results afterwards.

[Steven Watanabe via Boost]

AMDG

On 03/14/2018 03:25 AM, Daniel James via Boost wrote:
> On 12 March 2018 at 11:21, Stefan Seefeld via Boost
> <bo...@lists.boost.org> wrote:
>>
>> It might be worthwhile just merging the Boost.Build fix for now, without
>> merging anything in Boost.Python, as a minimal change to fix the issue.
>
> Steven, is it okay to merge build to master?
>

Yes. I'll handle it right now.

In Christ,
Steven Watanabe

[Daniel James via Boost]

On 14 March 2018 at 15:27, Steven Watanabe via Boost

<bo...@lists.boost.org> wrote:
> AMDG
>
> On 03/14/2018 03:25 AM, Daniel James via Boost wrote:
>> On 12 March 2018 at 11:21, Stefan Seefeld via Boost
>> <bo...@lists.boost.org> wrote:
>>>
>>> It might be worthwhile just merging the Boost.Build fix for now, without
>>> merging anything in Boost.Python, as a minimal change to fix the issue.
>>
>> Steven, is it okay to merge build to master?
>>
>
> Yes. I'll handle it right now.

Thanks, I've updated the super project.