- Boost - lists.boost.org

Re: [boost] Aggregate usage statistics request for Boost
by Dimitri John Ledkov 29 May '19

29 May '19

On Fri, 3 May 2019 at 10:03, Joshua Marshall <jrmarsha(a)mtu.edu> wrote: > > Hello all, > > A few of us with Boost are trying to decide support of different compilers. I know that Ubuntu collects some anonymized statistics which could help us some. Could someone please collect and forward the following bits of information to boost(a)lists.boost.org : > Install base size of Ubuntu 14.04 to 19.04 > Per OS version, what versions of GCC, Clang, and Boost are installed on what percentage of the install base. > -- > ubuntu-devel mailing list > ubuntu-devel(a)lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >From Ubuntu development point of view, our biggest concern is that no stable releases of boost claim to be supported or tested with the next GCC compiler. For example, for 19.10 we will be switching to GCC-9 by default, yet boost 1.70.0 primary test compilers do not include GCC-9 for Linux. Ideally, we would like to see boost upstream include next-gcc as part of primary or additional test compilers for every boost release. W.R.T. Install base size ratios and which boosts are in use -> we do not have statistics on what you are asking for. I.e. default compilers are installed on all systems (to support dkms), some boost runtime libraries are also always installed as quite a few packages depend on boost runtimes. And dev packages are not tracked and impossible to tell if they are installed by accident or on purpose. We can say generically, that our LTS releases are used a lot more than non-LTS releases, and thus by extension default compilers and boost versions within those are used more. And LTS cycles do follow an overlap, where for a while after one LTS release, the previous LTS is the most popular, and then it rolls over eventually. Our default compiler is GCC for all packages. LLVM toolchain is used for mesa and intel graphics compiler, and like that's it. Mesa requirements are what drives LLVM toolchain updates in Ubuntu. Next LTS 20.04 -> to be determined Current Development 19.10 -> 1.67.0, gcc 8.3 being switched to gcc 9, clang 8.0 (or newer) Current LTS releases (most popular at the moment) 18.04 -> 1.65.1, gcc 7.4, clang 6.0 16.04 -> 1.58.0, gcc 5.3, clang 3.8 Past basic support, in Extended Maintainance Support LTS (very old, and declining in usage) 14.04 -> 1.54.0, gcc 4.8, clang 3.4 12.04 -> 1.48.0, gcc 4.6, clang 3.0 -- Regards, Dimitri.

3 3

Re: [boost] [Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 29 May '19

29 May '19

> > > > Hi all, > > > > I'm working on a Boost.Exception issue [1] and I need to detect compiler > > support of std::current_exception. In the issue there is a suggestion to > > use #if __cplusplus > 199711L but that does not work for my use case > > (VS2015 reports __cplusplus = 199711L). > > MSVC defines _MSVC_LANG for this[1]. At least, it used to. However, it > would be cleaner to have a dedicated macro in Boost.Config for this. > Totally agree. > > > Is it possible to add a config macro for this? > > Or is there a good enough existing macro I can use? > > I don't think there is. Something like BOOST_NO_CXX11_HDR_EXCEPTION > would be useful. > I would need to detect support for std::current_exception, not the presence of header <exception>, so I would think that BOOST_NO_CXX11_CURRENT_EXCEPTION is what I need, right? So that I can #ifndef BOOST_NO_CXX11_CURRENT_EXCEPTION // I can use std::current_exception() unconditionally here #endif Should I open an issue in github for Boost.Config?

3 2

[Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 27 May '19

27 May '19

Hi all, I'm working on a Boost.Exception issue [1] and I need to detect compiler support of std::current_exception. In the issue there is a suggestion to use #if __cplusplus > 199711L but that does not work for my use case (VS2015 reports __cplusplus = 199711L). Is it possible to add a config macro for this? Or is there a good enough existing macro I can use? Thanks in advance [1] https://github.com/boostorg/exception/issues/10

2 1

My messages do not reach boost-request@lists.boost.org
by dariomt＠gmail.com 27 May '19

27 May '19

Hi, I've tried a couple of times to write to the Boost Developers mail list, but I don't see my messages getting through to the list. I seem to reach the Boost Users mil list without problems. Could you please review why this is happening? Thanks in advance!

1 0

Re: [boost] bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Peter Dimov 26 May '19

26 May '19

> Actually, bcp already has a list of things it can't figure out > automatically: > > https://github.com/boostorg/bcp/blob/develop/add_path.cpp#L195 > > which would need to be updated... ... with something like https://github.com/boostorg/bcp/commit/365e5e74f1708425ae542698730076e52acb… Unfortunately, after these fixes, everything seems to be copied correctly, but b2.exe then crashes. Something to do with `test` using `predef`, I assume, because if I delete libs/test, it then works.

1 0

Re: [boost] bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Peter Dimov 26 May '19

26 May '19

> It could probably be changed to copy libs/$LIB/config as a special case. Actually, bcp already has a list of things it can't figure out automatically: https://github.com/boostorg/bcp/blob/develop/add_path.cpp#L195 which would need to be updated with, I assume, std::pair<fs::path, fs::path>("libs/log/build", "libs/log/config"), and std::pair<fs::path, fs::path>("libs/test/build", "libs/predef/check"), or something like that.

1 0

Re: [boost] bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Peter Dimov 26 May '19

26 May '19

> But as a first step I think that we need to add a Travis test to tools/bcp > that exercises the scenario we want to fix. I've looked into this and we have some issues we probably need to address even before getting to namespace aliasing. 1. Since tools/boost_install and libs/headers are now needed by Jamroot, it might be better if we install them by default when `build` is requested. (libs/config is also needed by Jamroot, but almost every other library needs it as a dependency, so this usually doesn't manifest as a problem in practice.) 2. When I add them by hand, bcp installs more than needed, because tools/boost_install/test references a number of libraries such as container, log, python, and so on; we don't need these for typical uses. 3. Installing these libraries exposed issues with them: 3a. Log doesn't work because it has jamfiles in libs/log/config, which is not copied (just `build` and `src` are.) 3b. Test doesn't work because it uses predef.check in its Jamfile, but Predef is not copied. Apart from that, https://travis-ci.org/boostorg/bcp/builds/537447552

2 5

Re: [boost] bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Peter Dimov 26 May '19

26 May '19

> Apart from that, https://travis-ci.org/boostorg/bcp/builds/537447552 After fixing the two problems in Jamroot, testing the library after --namespace still doesn't work, because libs/program_options/test/Jamfile.v2 refers to the library as boost_program_options, but it's no longer called that.

1 0

[iostreams] Interest in multithreaded lzma filter?
by Mike 26 May '19

26 May '19

Accidentally only sent this to James and not the ML: > Gesendet: Donnerstag, 23. Mai 2019 um 15:19 Uhr > Von: "James E. King III" <jking(a)apache.org> > > > On Thu, May 23, 2019 at 8:39 AM Mike via Boost <boost(a)lists.boost.org> wrote: > > > > > Gesendet: Mittwoch, 22. Mai 2019 um 23:40 Uhr > > > Von: "Jeff Bonyun via Boost" <boost(a)lists.boost.org> > > > > > > > ... How will we detect whether > > > > liblzma is capable? If it is not capable but specified, will we allow > > > > the compression anyway? > > > > > > I've been investigating this. liblzma defines a version macro, > > > LZMA_VERSION. It looks like liblzma obtained its multithreaded function > > > in 5.1.1 (in 2011). So the idea would be to branch on this macro, and > > > fall back to the currently-used single-threaded function for an older > > > liblzma version. In that case, requesting any number of threads will > > > carry out the operation, but will only use a single thread. This makes > > > it tolerant of different versions, but does mark up the code with a few > > > #if branches. I'm assuming boost goes for tolerance in this case. > > > > Does a 2019 Boost release really have to be compatible with a Pre 2011 > > release of liblzma? Is this combination even tested? > > I.e. are we sure this would be the only incompatibility? > > > > How about just adding this functionality unconditionally and see if > > someone complains? > > > > So basically if someone has an older lzma they are limited to boost > 1.70.0 or earlier. That's perhaps reasonable as long as it is > documented, but it hasn't been the typical way I have seen things > added to existing code. Well, my second question was if you are confident that 1.70 does actually work with liblzma versions older than 5.1.1? If this isn't tested, it is not supported and if it is not supported it imho makes little sense to complicate the source code to achieve potential compatibility with (what I assume to be) a very, very small number of setups. > > Another way to handle it is to keep the old path in a macro like > BOOST_IOSTREAMS_NO_MULTITHREADED_LZMA. This is common through boost. > Ideally, detecting the liblzma version from the header could then set > BOOST_IOSTREAMS_NO_MULTITHREADED_LZMA and it would always do the right > thing, but the simplest way to do it is to let the consumer of the > library set this if they need it. > Personally I'm not a fan of configuration macros when they are not absolutely necessary because it effectively means you introduce yet another variant of boost that may or may not be tested and may or may not be compatible with the variant another dependency in my project was tested with (The total configuration space of boost is already far too large for my taste). As Robert Schumacher said in his cppcon talk: It's not just about you and the user, but also every library between you and the user. All of them now either have to support both choices or have to make one choice and hope they don't become incompatible with a different 3rd party library. Yet another reason, why package & dependency management is so hard in c++. However, as long as the interface is untouched by this macro I guess it would be fine. Best Mike

3 3

Non-ASCII Path Names in Repo
by Tom Kent 25 May '19

25 May '19

In the last few days we've had a non-ASCII path name added to the repo: tools/boostdep/test/utf8-test-ßµ™∃ Which came with commit 8893d1c57951a [1] I noticed this because a python 2 script (calling shutil.copytree) I had running on windows that copied the repo around started to fail. I've long needed to update that script to python 3, and am working on this. However, I wanted to point this out to the list so we could discuss if there are any other ramifications of having a non-ascii path. I vaguely remember some discussion about something like this in the past, but couldn't find it via search. If this is already a settled topic, that's great. Tom [1] https://github.com/boostorg/boostdep/commit/8893d1c57951a4a83705ed203005576…

2 1