- Boost - lists.boost.org

GSoC 2020 proposal review and GSoD
by Tom Kwok 29 Apr '20

29 Apr '20

Hi David (and other potential mentors), I updated my repository hosting my little project of C++ matrix classes for the GSoC competency test. Also, is there any editing needed for my proposal? I am sure you and other mentors are busy reviewing so I am sorry for bothering you with this message. If I don’t receive further feedback I would take it as no changes are needed (yet). Also, I read that Boost community is interested in participating GSoD (Google Season of Docs) as well. I would like to express my interest in GSoD participation and I look forward to hearing updates on specific requirements on GSoD participants and/or projects that Boost community may have. Best regards, Tom > On 23 Apr 2020, at 3:51 PM, boost-request(a)lists.boost.org <mailto:boost-request@lists.boost.org> wrote: > > Message: 8 > Date: Thu, 23 Apr 2020 08:25:22 +1000 > From: David Bellot <david.bellot(a)gmail.com <mailto:david.bellot@gmail.com>> > To: Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>>, Boost users list > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > Subject: [boost] 10 slots for the Google Summer of Code 2020 > Message-ID: > <CAOE6ZJGh_rM_Dg=h8SYktYoMqux2g+eAt7FiTaShJSs9UkeVMA(a)mail.gmail.com <mailto:CAOE6ZJGh_rM_Dg=h8SYktYoMqux2g+eAt7FiTaShJSs9UkeVMA@mail.gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > Hi Boost community, > > this year Google allocated 10 slots for the Google Summer of Code. It's > again a great achievement thanks to the hard work of our team of dedicated > mentors. > > We are now selecting the best students among all the proposals we receive. > We received 79 proposals this year. 10 of them will be selected. > > This year, a lot of proposals if not all are targeting a finalization of > the work which has been done in the previous GSoCs and we should see a lot > of code being pushed in production. It's a very exciting time for all of us. > > The mentors are now hard at work to choose the students. We'll keep you > informed when it's official. > > Best regards, > David

2 1

[release] Boost 1.73.0 Release Candidate 1
by Marshall Clow 28 Apr '20

28 Apr '20

The first release candidates for the 1.73.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.73.0/source/> The SHA256 checksums are as follows: d2e7501bb04fe7abc09aa93f013ae997604286a882da1bd36ddd96ea1163ea71 boost_1_73_0_rc1.7z 4eb3b8d442b426dc35346235c8733b5ae35ba431690e38c6a8263dce9fcbb402 boost_1_73_0_rc1.tar.bz2 9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf boost_1_73_0_rc1.tar.gz 0909a79524f857ef54570ceef8f397cc0629202532cc997785479c7c08bbc2a4 boost_1_73_0_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. -- The Release managers

9 22

Emails from Travis CI not coming?
by Andrey Semashev 28 Apr '20

28 Apr '20

Hi, Does anyone else have a problem with build result notifications from Travis CI not coming? I haven't received emails from Travis for about a month, although I can see the completed builds in the web UI. I checked spam, they aren't there.

2 4

CI Testing and failures
by Edward Diener 28 Apr '20

28 Apr '20

Sometimes CI testing fails because of a bug in a compiler. It is possible to designate in a jam file that a particular test should not be done for a particular compiler version so that CI testing succeeds, and therefore a PR can be more easily merged because the CI tests "succeed". But then the fact that the compiler has a bug is masked by such a change to the jam file. Is there a solution to such a problem, or maybe this is really not a problem at all ? What do others think about this ?

2 3

[release] 1.74.0 open for merging
by Marshall Clow 28 Apr '20

28 Apr '20

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/wiki/wiki/Releases%3A-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[release] Boost 1.73.0
by Marshall Clow 28 Apr '20

28 Apr '20

Release 1.73.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 2 new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.73.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.73.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Micheal Caisse and Glen Fernandes

1 0

Controlling _BOOST_CMAKEDIR in installed .cmake files
by Jonathan Wakely 24 Apr '20

24 Apr '20

With Peter Dimov's help I've resolved my earlier problems packaging Boost for Fedora. Now my problem is that the generated .cmake files contain the full --prefix path, which is not what I want because that's just a staging area, not the final resting place for the files (think DESTDIR in an autotools build). I see lines like this in each of the installed .cmake files: /builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake/boost_python-1.73.0/boost_python-config.cmake:if(EXISTS "/builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake") /builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake/boost_python-1.73.0/boost_python-config.cmake: get_filename_component(_BOOST_CMAKEDIR_ORIGINAL "/builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake" REALPATH) /builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake/boost_python-1.73.0/boost_python-config.cmake: set(_BOOST_CMAKEDIR "/builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake") These files won't work after everything gets moved from the staging area $RPM_BUILD_ROOT/usr/... to the final lcoation on a user's machine, under /usr/... I can just use sed to alter them, but surely there's way to set the desired prefix? I'm trying: ./bootstrap.sh --with-toolset=gcc --with-icu --prefix=/usr ./b2 -d+2 -q -j 4 \ --without-mpi --without-graph_parallel --build-dir=serial \ --prefix=/usr --libdir=/usr/lib64 \ variant=release threading=multi debug-symbols=on pch=off \ python=3.8 \ stage ... ./b2 -d+2 -q -j 4 \ --without-mpi --without-graph_parallel --build-dir=serial \ --prefix=$RPM_BUILD_ROOT/usr \ --libdir=$RPM_BUILD_ROOT/usr/lib64 \ variant=release threading=multi debug-symbols=on pch=off \ python=%{python3_version} \ install And this produces the .cmake files with the unwanted $RPM_BUILD_ROOT/usr prefixes. I originally didn't have the --prefix and --libdir options on the bootstrap.sh command and the 'b2 .. . stage' command, but it doesn't seem to matter whether they're there or not. Is there some way to control the prefix that ends up in those .cmake files?

2 2

Google Season of Docs
by David Bellot 24 Apr '20

24 Apr '20

Hi, The registration for organization is now open. If anyone is interested in managing this project and wish to talk about now, please let me know. I've got some experience now managing the Google Summer of Code and can help with GSoD too. Cheers, David

13 46

[thread] Determinig the thread API
by Edward Diener 23 Apr '20

23 Apr '20

What determines whether the Boost thread library is built with pthreads or win32 thread support if the threadapi feature is not specified when building the library ?

2 2

[release] Master branch now closed for 1.73.0 release
by Marshall Clow 23 Apr '20

23 Apr '20

1 0