- Boost - lists.boost.org

Posts not appearing on Boost Mailman
by Raffi Enficiaud 14 Aug '17

14 Aug '17

Hi Boost, I have an issue with MailMan: I never use "emails" for posting on the Boost ML, I use news.gmane.org through thunderbird. I can see my posts on news.gmane.org, but I cannot see any of my posts here for instance: https://lists.boost.org/Archives/boost/2017/07/index.php Is this normal? Thanks, Raffi

5 8

Hello World
by Naivedya Bansal 14 Aug '17

14 Aug '17

I am a new comer and would like to become a contributor at Boost. Could you please provide me with relevant links from where to start ad I am feeling entirely lost right now. Thank you, Naivedya Bansal

2 1

CUDA V9 (release candidate) breaks compilation
by Hartmut Kaiser 12 Aug '17

12 Aug '17

All, Apparently CUDA V9 has deprecated/removed the __CUDACC_VER__ macro which is used by Boost, see https://github.com/STEllAR-GROUP/hpx/issues/2815 for details. Should this be fixed before the release? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

1 0

Switch to CMake -- Analysis
by Thomas Heller 12 Aug '17

12 Aug '17

Hi list, After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations... First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake. Unfortunately, there doesn't seem to be any overlap between those groups, which generally made the discussions about a potential switch to CMake unfruitful, often leading to misunderstandings due to a lack of knowledge about the other tool. There is no doubt, that the group of people knowing CMake is larger and that projects using CMake far outnumber the ones using Boost.Build. A thousand flies can't be wrong, right? Is the popularity of CMake really the only benefit? Here is the thing, from my point of view: Apart from the different philosophy (Build System vs. Build System generator), in the end, you get a executable/library out of the system. From a pragmatic point of view, the only thing that changes to develop/build/test/use a library is the work flow. Leaving aside the disruptive and its effects of such. Now, on to the motivation for switching, as presented in the announcement: On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote: > [...] our build system has become an impediment for many developers > and users, existing and prospective. Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit. Now on to developers. There is obviously a lot of resistance from existing developers (for various reasons, which are not really relevant for the discussion at hand). In my opinion, maintaining two build systems is a no-go. Either make a clear cut, or don't. Please don't waste resources on maintaining and supporting both. With this line of thought as the background, this will create massive disruption. Switching the whole of boost (including infrastructure, documentation etc.) to be built and tested with CMake is not easy and take a lot of time, leaving a void for both maintainers and prospective boost library authors. Now, the argument that has been brought up very often in favor for the switch is that it will attract more contributors, but will it really? I am reluctant to the idea that people don't contribute new libraries to boost just because of the build system. Despite a switch to cmake, you'd still have to conform to Boost.CMake guidelines and somehow make your library buildable and testable within and outside of the Boost Tree (there might be a straight forward solution to this). Furthermore, I often hear something like "in the presence of GitHub and CMake people don't think about submitting to boost anymore". This is exactly the point. But it has nothing to do with the "and CMake" suffix. It's is just far more easier and convenient to drop you library to GitHub, advertise it on various channels and call it a day. I hear you say: "Sure, but libraries will only be adopted if they come with CMake." That might very well be true, but what has this to do with Boost? Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either ;) All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config). While your add it, improve Boost.Build, maybe it can rise again from its ashes (why did it "fail" in the first place?). Regards, Thomas

27 78

Best Practices for Surviving the Boost Test Gauntlet?
by Vinnie Falco 11 Aug '17

11 Aug '17

Beast won the first battle, but it looks like it is losing the war: <http://www.boost.org/development/tests/develop/developer/beast.html> I've never heard of many of these platforms let alone know how to go about fixing the compile, link, and runtime errors. It seems like deallocate() is not part of some standard library's allocator_traits? Link error on operator delete from Boost.System? A lot of little thing. Is there a document or resource which explains the various peculiarities and idiosyncrasies of these platforms and toolchains that I might have a means of fixing them without actually installing them locally (which is unlikely)? Thanks

6 14

boost_check_library.py: correct handling of header-only libs?
by Vinnie Falco 10 Aug '17

10 Aug '17

This script fails for me: <https://github.com/boostorg/boost/blob/master/status/boost_check_library.py…> Because there is no libs/beast/build. But Beast is header-only and has no src/ directory, is this correct? Apologies for posting to the list, but there is no Issues tab on the boostorg/boost repo. Thanks

3 2

Boost 1.65.0 Release Candidate 1
by Marshall Clow 09 Aug '17

09 Aug '17

The release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ The SHA256 checksums are as follows: 0f1352a7738f24b39b564263b66a8c38bc7d984b57406396400474602e961ad3 boost_1_65_0_rc1.7z c2a022d4d6706668ea94b8e799a76e38929e0e34db884ef451fa9d5db6103238 boost_1_65_0_rc1.tar.bz2 7e84a27276792209d48357a0671348768dbf4dd1d4eadbf01b855274208f148d boost_1_65_0_rc1.tar.gz 537c42771b2351b4ea3eb8e9a13a3423edcd155323d2c14c4606cd23fc22d09f boost_1_65_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. Thanks! -- The release managers

7 12

[filesystem] Pull request needs attention
by Robert Dailey 09 Aug '17

09 Aug '17

I have fixed a crash I found due to static initialization ordering in boost filesystem. I have a proposed fix here: https://github.com/boostorg/filesystem/pull/47 It hasn't gotten any attention yet, so I'm hoping someone can offer some advice and/or merge the PR for me. Thanks in advance.

3 3

Boost UUID Maintainer
by James E. King, III 08 Aug '17

08 Aug '17

Greetings! I'm a long-time boost user and over the years I have posted defects into boost trac for the components I have used. I was reviewing the backlog on boost::uuid and in trac and it needs a bit of grooming. I started submitting some PRs to resolve some of these. Edward D. in the CMT group was reviewing some of them and mentioned that there is no active maintainer for the library, and invited me to introduce myself here. I am currently a committer on the Apache Thrift project and I have 20+ years development experience with C++. I have good experience at backlog grooming, and I am very focused on quality. I believe firmly in testing all code branches, and using coverage tools to prove it. I also assisted the glibc team in getting started with Coverity Scan which helped lead to resolution of 138 defects at last count. My current position is a Software Architect at HPE SimpliVity where I have been for the last ~7 years (I'm easy to find on LinkedIn, hopefully). I live in Westford, MA, USA. Given there is no maintainer for boost::uuid currently, I would like to petition for that responsibility. It is a relatively small library in the portfolio and seems like a good introduction to being a maintainer in such a widely used project. Thanks for your consideration, Jim King

5 7

[stacktrace] 1.65.0 RC1 fails to build for MSYS2/mingw-w64
by Stephan Lavavej 07 Aug '17

07 Aug '17

Hi, I just attempted to build Boost 1.65.0 RC1 with MSYS2/mingw-w64. (My build script for 1.64.0 is available at https://github.com/StephanTLavavej/mingw-distro/blob/6e5976af8c63de93bec761… ; I just had to change the filenames for 1.65.0 RC1.) The stacktrace build failed with: gcc.compile.c++ bin.v2\libs\stacktrace\build\gcc-mingw-7.1.0\release\link-static\runtime-link-static\threading-multi\windbg_cached.o In file included from libs\stacktrace\build\..\src\windbg_cached.cpp:10:0: ./boost/stacktrace/detail/frame_msvc.ipp:167:72: warning: missing terminating ' character # error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED. ^ ./boost/stacktrace/detail/frame_msvc.ipp:167:5: error: #error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED. # error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED. ^~~~~ In file included from ./boost/detail/winapi/file_management.hpp:17:0, from ./boost/stacktrace/detail/safe_dump_win.ipp:20, from ./boost/stacktrace/safe_dump_to.hpp:206, from ./boost/stacktrace/frame.hpp:20, from ./boost/stacktrace/detail/frame_msvc.ipp:15, from libs\stacktrace\build\..\src\windbg_cached.cpp:10: ./boost/detail/winapi/overlapped.hpp:39:9: warning: ISO C++ prohibits anonymous structs [-Wpedantic] }; ^ "g++" -O3 -finline-functions -Wno-inline -Wall -pedantic -mthreads -m64 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2\libs\stacktrace\build\gcc-mingw-7.1.0\release\link-static\runtime-link-static\threading-multi\windbg_cached.o" "libs\stacktrace\build\..\src\windbg_cached.cpp" ...failed gcc.compile.c++ bin.v2\libs\stacktrace\build\gcc-mingw-7.1.0\release\link-static\runtime-link-static\threading-multi\windbg_cached.o... It appears that frame_msvc.ipp is intended to work with both MSVC and MinGW, but it's not correctly recognizing mingw-w64 GCC 7.1.0's behavior. This compiler supports thread_local, although it doesn't support C++11's multithreading headers (without the pthreads wrapper, which I don't build). Either this library should correctly detect mingw-w64, or it should be disabled for mingw-w64. Thanks, STL

2 2