On Fri, Jul 19, 2019 at 6:22 AM Tom Kent wrote:

On Thu, Jul 18, 2019 at 5:43 PM Michael Caisse via Boost < boost@lists.boost.org> wrote:

...

Boost release 1.71.0 beta 1 is now available at:

https://dl.bintray.com/boostorg/beta/1.71.0.beta1.rc1/source/

The SHA256 checksums are as follows:

451adc4f199c73e995e541f38c4dbd51faf4ce0db15537136ffd5213a1be5e55 boost_1_71_0_b1_rc1.7z

a93d7066fc1514995aec0e726532a219447dd39b0ffa7cb97ca5736f16b0488b boost_1_71_0_b1_rc1.tar.bz2

34743b80466463e0c1b7fc71b677f326bdc242fe0b87a9c1599b6f7ea6e5c0cb boost_1_71_0_b1_rc1.tar.gz

5cd448bddc8394469391306e0ccada0a8f88c5c6cf8ec775ddf8e56adef8bbc2 boost_1_71_0_b1_rc1.zip

For details of what's in the release, see http://www.boost.org/users/history/version_1_71_0.html.

Note: Having some trouble getting the web page updated... check back with it soon.

Please download the beta, give it a try, and report any problems you encounter.

Thanks,

-- The Boost Release Team

The directory is "RC1", is this the usual pre-beta RC series that we usually go through, or did the release team skip RC announcements this time?

For what its worth, this RC looks good on windows/visual studio. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X 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 msvc-14.2 32 X X X msvc-14.2 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. Tom

On 7/19/19 04:22, Tom Kent wrote:

On Thu, Jul 18, 2019 at 5:43 PM Michael Caisse via Boost mailto:boost@lists.boost.org> wrote:

Boost release 1.71.0 beta 1 is now available at:

https://dl.bintray.com/boostorg/beta/1.71.0.beta1.rc1/source/

The SHA256 checksums are as follows:

<snip>

Please download the beta, give it a try, and report any problems you encounter.

Thanks,

-- The Boost Release Team

The directory is "RC1", is this the usual pre-beta RC series that we usually go through, or did the release team skip RC announcements this time?

Tom 

This is my mistake. The pre-beta RC series got skipped. I did a lot of local testing and didn't fully understand the steps Marshall had been following. In short, if Tom thinks this package looks good then it is also the Beta1. Sorry about the confusion and thank you for the feedback. The next round will be executed better. michael -- Michael Caisse Ciere Consulting ciere.com

On 7/19/19 11:16, Tom Kent wrote:

On Fri, Jul 19, 2019 at 4:14 PM Michael Caisse mailto:mcaisse-lists@ciere.com> wrote:

On 7/19/19 04:22, Tom Kent wrote: >

<snip>

This is my mistake. The pre-beta RC series got skipped. I did a lot of local testing and didn't fully understand the steps Marshall had been following.

In short, if Tom thinks this package looks good then it is also the Beta1. Sorry about the confusion and thank you for the feedback. The next round will be executed better.

I'm not wild about changing the release process on the fly, especially if it eliminates the community's testing of RCs. I do a bunch of tests, but they are limited to the Windows/Visual Studio configurations, there's a much more diverse audience out there that we often get feedback from. 

That said, if this is Beta1, I'll upload these binaries as the windows packages to bintray. (uploading now, should be visible in a few minutes)

Can you please fix the file names on bintray so that the beta release doesn't include the rc1 in the path or file name? E.g. the files should be at: https://dl.bintray.com/boostorg/beta/1.71.0.beta1/source/boost_1_71_0_b1.* 

Just like they were for 1.70: https://dl.bintray.com/boostorg/beta/1.70.0.beta1/source/boost_1_70_0_b1.tar...

I'll make a new bintray package without the rc. As I mentioned, this was my mistake. The process wasn't purposely changed on-the-fly. That said, it is the beta and other than the smoke test of an RC for the beta, community testing against a beta is appropriate. Putting a beta out that doesn't build at all for the most popular platforms would be a mistake and as a result we have release candidates for the beta. If you are using the term "community testing" to mean specifically you in the context of Windows builds, then I agree that there is a lot of value to that in an RC of the beta. If you mean that the community as a whole should test an RC of a beta before we have a beta ... I'm probably missing the value. -- Michael Caisse Ciere Consulting ciere.com

On 7/24/19 12:28 PM, Niall Douglas via Boost wrote:

On 18/07/2019 23:43, Michael Caisse via Boost wrote:

...

Please download the beta, give it a try, and report any problems you encounter.

Testing Outcome on MSVC, I get:

C:\Users\ned\Downloads\boost_1_71_0_b1_rc1\boost_1_71_0\libs\outcome\test>..\..\..\b2 toolset=msvc-14.0 Performing configuration checks

- default address-model : 32-bit - default architecture : x86 - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes ...found 1 target...

Outcome's Jamfile requires:

project : requirements [ requires cxx14_variable_templates cxx14_constexpr ] [ predef-require "!BOOST_COMP_GNUC" or "BOOST_COMP_GNUC >= 6.0" ] [ predef-require "!BOOST_COMP_CLANG" or "BOOST_COMP_CLANG >= 4.0" ] <define>BOOST_TEST_MODULE=Outcome <library>../../test/build//boost_unit_test_framework ;

So, the fact that !BOOST_COMP_GNUC and !BOOST_COMP_CLANG are false on MSVC is a problem, the tests won't run on MSVC.

Yet Outcome works fine for the developer build, as evidenced by the regression matrix. So this is a problem affecting this release build ONLY.

Thoughts?

I've not used predef-require, but you can't compare versions in dotted notation in C++ preprocessor. Boost.Predef defines version numbers with BOOST_VERSION_NUMBER, so you would compare like this: BOOST_COMP_GNUC >= BOOST_VERSION_NUMBER(6, 0, 0) Also, note that 6.0 is a pre-release version of gcc 6.x. The first release version is 6.1. That said, given that the Boost.Build output above is from MSVC, I'm not sure why both !BOOST_COMP_GNUC and !BOOST_COMP_CLANG are "no".

On Wed, Jul 24, 2019 at 11:21 AM Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

...

So, the fact that !BOOST_COMP_GNUC and !BOOST_COMP_CLANG are false on MSVC is a problem, the tests won't run on MSVC.

Yet Outcome works fine for the developer build, as evidenced by the regression matrix. So this is a problem affecting this release build ONLY.

Thoughts?

I've not used predef-require, but you can't compare versions in dotted notation in C++ preprocessor. Boost.Predef defines version numbers with BOOST_VERSION_NUMBER, so you would compare like this:

BOOST_COMP_GNUC >= BOOST_VERSION_NUMBER(6, 0, 0)

Also, note that 6.0 is a pre-release version of gcc 6.x. The first release version is 6.1.

I vaguely remember that the documented approach, which is what you suggest, doesn't work from Predef. What I have in there does work. GCCs before 6 are excluded, that works fine.

...

That said, given that the Boost.Build output above is from MSVC, I'm not sure why both !BOOST_COMP_GNUC and !BOOST_COMP_CLANG are "no".

It also would seem that Predef is broken on GCC 7.3 on Linux as well:

ned@KATE:/mnt/c/Users/ned/Downloads/boost_1_71_0_b1_rc1/boost_1_71_0$ ./b2 libs/outcome/test Performing configuration checks

- !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - default address-model : 64-bit - default architecture : x86 - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes ...found 1 target...

Just to make sure that the BOOST_VERSION_NUMBER thing hadn't changed:

ned@KATE:/mnt/c/Users/ned/Downloads/boost_1_71_0_b1_rc1/boost_1_71_0$ ./b2 libs/outcome/test --reconfigure Performing configuration checks

- !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= BOOST_VERSION_NUMBER(6, 0, 0) : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= BOOST_VERSION_NUMBER(4, 0, 0) : no - default address-model : 64-bit - default architecture : x86 - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= BOOST_VERSION_NUMBER(6, 0, 0) : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= BOOST_VERSION_NUMBER(4, 0, 0) : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes ...found 1 target...

So I'd say b2 predef has become broken recently. At least in the release distro, as the regression matrix shows Outcome building: https://www.boost.org/development/tests/develop/developer/outcome.html

It certainly looks broken.. I'll take a close look next week when I'm back in the States. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

On Thu, Jul 25, 2019 at 5:11 AM Peter Dimov via Boost wrote:

Michael Caisse wrote:

...

Please download the beta, give it a try, and report any problems you encounter.

FWIW, Stacktrace no longer compiles under msvc-9.0, because

compile-c-c++

bin.v2\libs\stacktrace\build\msvc-9.0\release\link-static\threading-multi\windbg.obj windbg.cpp .\boost/stacktrace/detail/frame_msvc.ipp(118) : error C2039: 'back' : is not a member of 'std::basic_string<_Elem,_Traits,_Ax>' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] .\boost/stacktrace/detail/frame_msvc.ipp(118) : fatal error C1903: unable to recover from previous error(s); stopping compilation

I see that Tom is no longer building msvc-9.0 binaries though, so this may not be a problem.

We also don't have anyone running msvc-9.0 testers in the matrix anymore, so that is probably why it hasn't been noticed. Last december there was a thread [1] about dropping support for older compilers. The general consensus was that we'd focus around msvc-10.0+, gcc-4.6+, clang-3.4+. However, if there are easy fixes that help older compilers (like this!) there is no reason to not apply them. Tom [1] https://lists.boost.org/Archives/boost/2018/12/244632.php

Antony Polukhin wrote:

MSVC-9 is also not supported by Appveyor.

It is, that's where I saw the error. https://ci.appveyor.com/project/pdimov/check-build/builds/26225072