[release] Boost 1.67.0 Beta 1 Release Candidate 1

Daniel James

10 Mar 2018 10 Mar '18

7:57 p.m.

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.

Show replies by date

Andrzej Krzemienski

10 Mar 10 Mar

11:41 p.m.

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 , 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 ^~~~~~~~~~~~ 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; 2018-03-10 20:57 GMT+01:00 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

Daniel James

11 Mar 11 Mar

10:17 p.m.

On 10 March 2018 at 23:41, Andrzej Krzemienski 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 , 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 ^~~~~~~~~~~~ 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

11:38 p.m.

On 12/03/2018 11:17, Daniel James wrote:

...

On 10 March 2018 at 23:41, Andrzej Krzemienski 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 , 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 ^~~~~~~~~~~~ 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.

Lorenzo Caminiti

12:26 a.m.

Hello Daniel and all, On Sat, Mar 10, 2018 at 11:57 AM, Daniel James via Boost 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

Olaf van der Spek

9:08 a.m.

On Sat, Mar 10, 2018 at 8:57 PM, Daniel James via Boost 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

10:27 a.m.

On 11 March 2018 at 09:08, Olaf van der Spek 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/d4d41d94aecc9f8098aabd3587fcb95458... I think the best thing to do is revert that commit, or maybe the recent changes to python.

Stefan Seefeld

1:27 p.m.

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/d4d41d94aecc9f8098aabd3587fcb95458..., 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, On 11.03.2018 05:08, Olaf van der Spek via Boost wrote:

...

On Sat, Mar 10, 2018 at 8:57 PM, Daniel James via Boost 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?

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

Daniel James

1:59 p.m.

On 11 March 2018 at 13:27, Stefan Seefeld via Boost 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/d4d41d94aecc9f8098aabd3587fcb95458..., 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.

Stefan Seefeld

2:33 p.m.

On 11.03.2018 09:59, Daniel James 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/d4d41d94aecc9f8098aabd3587fcb95458..., 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

On 11 March 2018 at 13:27, Stefan Seefeld via Boost wrote: 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.

Oh. In that case https://github.com/boostorg/python/commit/0021720a464742aec04b996e55c7f04560... may be the solution ? Stefan -- ...ich hab' noch einen Koffer in Berlin...

Steven Watanabe

6:10 p.m.

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/d4d41d94aecc9f8098aabd3587fcb95458..., 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/0dacbc3df69fbbb443f1ecaa0ee57c0157d... 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

12 Mar 12 Mar

10:45 a.m.

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

...

I fixed this in https://github.com/boostorg/build/commit/0dacbc3df69fbbb443f1ecaa0ee57c0157d... 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

11:21 a.m.

On 12.03.2018 06:45, Daniel James via Boost wrote:

...

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

...
I fixed this in https://github.com/boostorg/build/commit/0dacbc3df69fbbb443f1ecaa0ee57c0157d... 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/0021720a464742aec04b996e55c7f04560... https://github.com/boostorg/python/commit/6b8ab7a5a3f0ef263055cb2a4b745d1304... 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

14 Mar 14 Mar

9:25 a.m.

On 12 March 2018 at 11:21, Stefan Seefeld via Boost 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?

Steven Watanabe

3:27 p.m.

AMDG On 03/14/2018 03:25 AM, Daniel James via Boost wrote:

...

On 12 March 2018 at 11:21, Stefan Seefeld via Boost 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

3:56 p.m.

On 14 March 2018 at 15:27, Steven Watanabe via Boost 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 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.

Tom Kent

11 Mar 11 Mar

12:39 p.m.

On Sat, Mar 10, 2018 at 1:57 PM, Daniel James via Boost < boost@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_... 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_... 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/ove...) (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.

Daniel James

1:50 p.m.

On 11 March 2018 at 12:39, Tom Kent via Boost 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.

Peter Dimov

2:14 p.m.

Daniel James wrote:

...

On 11 March 2018 at 12:39, Tom Kent via Boost 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

Daniel James

3:02 p.m.

On 11 March 2018 at 14:14, Peter Dimov via Boost wrote:

...

Daniel James wrote:

...
On 11 March 2018 at 12:39, Tom Kent via Boost 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?

Peter Dimov

3:29 p.m.

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.

Oliver Kowalke

3:02 p.m.

2018-03-11 14:50 GMT+01:00 Daniel James via Boost :

...

On 11 March 2018 at 12:39, Tom Kent via Boost 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

Oliver Kowalke

2:52 p.m.

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

Daniel James

3:05 p.m.

On 11 March 2018 at 14:52, Oliver Kowalke via Boost 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.

Vinnie Falco

5:29 p.m.

On Sat, Mar 10, 2018 at 11:57 AM, Daniel James via Boost 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

Daniel James

12 Mar 12 Mar

1:36 p.m.

On 10 March 2018 at 19:57, Daniel James 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.

Tom Kent

14 Mar 14 Mar

1:30 p.m.

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

...

On 10 March 2018 at 19:57, Daniel James 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

1:33 p.m.

On 14 March 2018 at 13:30, Tom Kent via Boost wrote:

...

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

...
On 10 March 2018 at 19:57, Daniel James 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

1:36 p.m.

On Wed, Mar 14, 2018 at 8:33 AM, Daniel James via Boost < boost@lists.boost.org> wrote:

...

On 14 March 2018 at 13:30, Tom Kent via Boost wrote:

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

...
On 10 March 2018 at 19:57, Daniel James 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

1:39 p.m.

On 14 March 2018 at 13:36, Tom Kent via Boost wrote:

...

On Wed, Mar 14, 2018 at 8:33 AM, Daniel James via Boost < boost@lists.boost.org> wrote:

...
On 14 March 2018 at 13:30, Tom Kent via Boost wrote:

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

...
On 10 March 2018 at 19:57, Daniel James 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?

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

2433

Age (days ago)

2437

Last active (days ago)

List overview

Download

29 comments

11 participants

participants (11)

Andrzej Krzemienski
Daniel James
Gavin Lambert
Lorenzo Caminiti
Olaf van der Spek
Oliver Kowalke
Peter Dimov
Stefan Seefeld
Steven Watanabe
Tom Kent
Vinnie Falco