- Boost - lists.boost.org

Boost 2 and build2
by Boris Kolpackov 25 Oct '18

25 Oct '18

I've noticed the discussion on Boost 2 where build2 was mentioned as one of the potential build systems. So I wanted to say that we would be happy to help on our side with any questions, missing features (like exporting targets in a CMake-compatible manner, as mentioned by Niall), etc. Also a couple of additional points about build2 that I think could be relevant to Boost 2 (or 1): 1. It is currently the only build system that I am aware of that has support for C++ modules (currently TS but we are tracking the standardization/implementation progress closely; see [1] for details). Now that modules are likely to be in C++20 I think this should be at least a consideration for Boost 2. 2. We have a public CI service[2] for open source project that I think could be quite useful to Boost. It might not currently be as extensive as Boost's (see [3] for the currently offered build configurations) but we are continuously expanding it plus Boost can run its own build machines with additional configurations. 3. build2 comes with a package manager[4] and Boost could take advantage of that by either publishing to cppget.org or running its own package repository (or both). I am happy to answer any questions here (if appropriate, of course), on the build2 mailing list[5], or on the #build2 slack channel[6]. [1] https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules [2] https://ci.cppget.org [3] https://ci.cppget.org/?build-configs [4] https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#guide-… [5] https://lists.build2.org/ [6] https://cpplang.slack.com/app_redirect?channel=build2

1 0

The future and present of Boost
by Robert Ramey 25 Oct '18

25 Oct '18

This was on another thread. Someone mentioned that it should be on it's own thread so here it is (slightly amended for context). For some time I've been concerned about the future of Boost as an organization. Here are the concerns I have: a) With C++11, the standards committee accepted a large portion of Boost into the standard. This left it unclear as to what the future value of Boost to C++ might be. b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost, which helps to evolve "establish practice" outside of the development of the C++. An example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost - that is, makes it less relevant and important. c) This effort by the committee is basically failing. It's creating the possibility that C++ will evolve into an ever larger and incomprehensible bag of disjoint features than it already is. It makes it much harder to learn C++. This puts C++ on a slow train to oblivion. This is not unusual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organizations, universities - etc. All one has to do to see this is look at the papers list for the San Diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO. Of course the C++ committee won't address the situation. Committees don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling. Wake up and smell the coffee people. Learn to prioritize and limit the scope of your actions to that which only you can do. This would be better for C++. Do less - get more done! d) Boost can accept, review and deliver a new library in a year. Hence Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas. Robert Ramey

23 70

warning: non-free usage requirements <threading>multi ignored
by blubee blubeeme 25 Oct '18

25 Oct '18

Hello I am trying to build boost from git clone I run bootstrap.sh with these flags ```shell ./bootstrap.sh \ --prefix=/usr/local \ --with-toolset=clang \ --with-icu=/usr/local \ --with-python=python27 \ ``` After boostrapping I append ```shell "using mpi ;" >> ./project-config.jam ``` There's two issues with that 1)icu isn't found even though icu headers are in /usr/local/unicode/ 2)I get this this warning ```error warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:144 ``` Which I tracked down to this issue: http://boost.2283326.n4.nabble.com/explicitly-specified-values-of-non-free-… That thread leaves the issue unresolved and just throws a warning instead of failing. ```shell ./bjam \ --prefix=/usr/local \ --layout=system \ -d4 \ --toolset=clang \ --build-dir=./build \ --stagedir=/opt/boost \ -j4 \ include=/usr/local/include/unicode \ link=shared \ threading=multi \ stage \ ``` bjam output ```shell Performing configuration checks - default address-model : 64-bit - default architecture : x86 - symlinks supported : yes - C++11 mutex : yes - lockfree boost::atomic_flag : no - 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_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 : yes warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at project-config.jam:42 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:119 - zlib : yes - bzip2 : yes - lzma : yes - zstd : no - iconv (libc) : yes - icu : no - icu (lib64) : no - xlocale supported : yes - native-atomic-int32-supported : yes - native-syslog-supported : yes - pthread-supports-robust-mutexes : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : no warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:144 - libbacktrace builds : no - addr2line builds : yes - WinDbg builds : no - WinDbgCached builds : no - BOOST_COMP_GNUC >= 4.3.0 : no Component configuration: - atomic : building - chrono : building - container : building - context : building - contract : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ``` I do have a working installation of openmpi installed in /usr/local and mpicxx is in my path from following the directions here: https://www.boost.org/doc/libs/1_64_0/doc/html/mpi/getting_started.html#mpi… in the end the build errors out ```shell 0.003049 sec system; 0.000000 sec user; 3.078255 sec clock Using shell: /bin/sh -c argv[0] = '/bin/sh' argv[1] = '-c' argv[2] = ' ln -f -s 'libboost_wave.so.1.69.0' '/wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so' ' ln-UNIX /wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so ln -f -s 'libboost_wave.so.1.69.0' '/wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so' 0.001905 sec system; 0.000000 sec user; 1.957884 sec clock ...failed updating 86 targets... ...skipped 17 targets... ...updated 1147 targets... *** [do-build] Error code 1 make: stopped in /usr/ports/devel/boost-devel 1 error ``` two questions: 1) How do I solve the non-free usage requirements warning 2) Why isn't icu being picked up? github issue:: https://github.com/boostorg/boost/issues/210

1 0

Library devs only: Boost v2.x distro design questions
by Niall Douglas 24 Oct '18

24 Oct '18

Splitting this off from the other thread, can I get feedback from Boost library maintainers ONLY. Not users, not non-maintainers. Q0: Are you willing to do the work to adapt your library for any Boost v2.x distro if it were to happen? Q1: Would you prefer a new, separate Boost v2.x distro in parallel to the v1.x distro, or to keep everything within one v1.x distro? Q2: Would you be intending to keep your library inside Boost v1.x, move it exclusively to Boost v2.x, or have it exist in both Boost v1.x and v2.x but with different defaults configured? Also, would the version in v1.x be hard forked from any v2.x edition i.e. the v1.x edition would get orphaned? Q3: What C++ standard should Boost v2.x's master build system be defaulted to? C++ 11, 14, 17 or 20? Q4: Should Boost v2.x use a boost2 namespace, or namespace boost { inline namespace v2 { }}? (This affects whether Boost v2 and v1 editions of your library can be used within the same translation unit) Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake, Build2, something else? Q6: Should Boost v2.x's libraries auto integrate individually into some package manager? If so, which ones do you intend to support? Q7: Should Boost v2.x have official release versions done by release managers, or should it be a rolling release of "whatever last passed the CI @ 100%"? Note that you can have this, and have official release versions of "especially known good" editions too. Q8: Should Boost v2.x use a local HTML server to serve documentation, and the static HTML docs be dispensed with as a requirement? Q9: What are your feelings towards the use of Python to script infrastructure and tooling in any Boost v2.x? For example, Python to run a local HTML server to serve documentation locally, or Python to build a release etc Q10: What parts of core Boost are you utterly dependent upon, and would absolutely need ported to any Boost v2.x as no STL alternatives exist? I could go on, but let's stop there for now. Niall

2 4

Re: [boost] [release] 1.69.0 deadline for new libraries approaching
by Peter Dimov 24 Oct '18

24 Oct '18

> Robert Ramey wrote: > > On 10/22/18 10:19 AM, Peter Dimov via Boost wrote: > > > Marshall Clow wrote: > > > > > >> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes > > > > > > OK... do we want CMake config files installed by 1.69 or not, then? > > > > I'd like to know this as well. If so, I presume that we can consider > > the Boost/CMake issues resolved and we can just move on from this? > > I doubt it. The CMake issue is much bigger than this. To expand on that: The Boost/CMake issues concern four scenarios: 1. CMake users who want to use a pre-built Boost from CMake, after installing it either with `b2 install`, as usual, or via some other mechanism; 2. CMake users who want to use Boost (or an individual Boost library) from CMake without building it with b2 and installing it, but as a subproject, built by CMake; 3. Building and installing Boost with CMake, replacing the current Boost.Build building/installing infrastructure; 4. Testing Boost with CMake, replacing the current Boost.Build testing infrastructure. Installing CMake config files as part of `b2 install` falls into scenario number 1. Boost is still built with Boost.Build as always, it's just that in addition to libboost_foo.a, the user also gets libboost_foo.cmake, which allows him to do `find_package(boost_foo)` from his CMakeLists.txt file. Nothing more than that. This doesn't affect, doesn't target, and doesn't address, scenarios 2-4 at all.

8 25

boost-cmake and quickbook
by Raffi Enficiaud 23 Oct '18

23 Oct '18

On 23.10.18 21:29, Edward Diener via Boost wrote: > On 10/23/2018 2:36 PM, Robert Ramey via Boost wrote: >> On 10/23/18 11:17 AM, Peter Dimov via Boost wrote: >>> Robert Ramey wrote: >>> >>>> And I place the html and pdf versions into the repo so users don't have to build it. >>> >>> Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides. >> >> Both true. >> >> downside >> - "wastes" a lot of space >> - redundant - docs could get out sync with the code. >> >> >> upside >> >> - current documentation is always available to the user. In the two libraries of mine - documentation is an important part and I don't think the either would be usable without them. >> - only needs to be built on one machine no hassle for users >> - document build doesn't have to be "portable" >> - potential users can easily browse the documentation before they clone/download the package. This works well with github. I think this is very valuable - especialy for safe_numerics which most people don't actually see the need for. Call it a sales tool. > > I am sure you know that github already has support for viewing the documentation via the github io mechanism, so your last '-' item is not really applicable to your argument. > > My argument is simply that lots and lots of libraries use Boost Build to generate the docs, very often through the quickbook -> docbook -> pdf/html mechanism and unless we are going to continue to do it that way when Boost uses CMake we will eventually need a way to duplicate the Boost Build mechanism for creating the docs in CMake. > > Nonetheless I continue to believe that the move to CMake by Boost should be achieved in small steps, so that we can assure success in one step for all libraries before we even think about attempting the next. I still have the same fear that trying to accomplish everything at one time will mean that nothing really will ever get done. I only added item 5) to Peter's list because that is something we will eventually have to decide about. [sorry for multiple posting] Talking about small steps, feel free to copy paste this wherever you need it: https://github.com/raffienficiaud/boost-cmake/blob/master/boost-cmake/quick… I compiled Boost.Test documentation with this, this is fully cmake and it does the catalog generation on the fly. This is a small step, usually this is where collaboration starts, since I do not have all the knowledge of quickbook/docbook nor the bandwidth ATM. *But* if somebody is kind enough to assist me on this, in particular explaining me if we would want --stringparam chunk.first.sections "1" --stringparam chunk.section.depth "4" --stringparam generate.section.toc.level "3" --stringparam html.stylesheet "boostbook.css" --stringparam toc.max.depth "3" --stringparam toc.section.depth "10" to be exposed when compiling a documentation, or how to run the doxygen part, then porting things to cmake will be definitely faster. Raffi _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[preprocessor] vc++ using the experimental preprocessor
by Edward Diener 23 Oct '18

23 Oct '18

I have updated on the 'develop' branch Boost PP code that will use the vc++ C++ standard conforming preprocessor in VS2017 15.8 and above, as explained at https://blogs.msdn.microsoft.com/vcblog/2018/07/06/msvc-preprocessor-progre…. The code essentially treats vc++ in this mode as a strictly standard conforming preprocessor. There is the switch of /experimental:preprocessor which turns on the new preprocessor for the end-user, else the normal non-standard vc++ preprocessor is still the current default. BTW I tried to post a comment to the link above, explaining that the test posted in the article for the new preprocessor was wrong, but for whatever reason it never was actually posted as a comment. Nonetheless I got it right for myself in the Boost PP code in its config.hpp, so I am not going to worry about the fact that others may use the erroneous test in the article in their code. The change I made to Boost PP does not affect any other compiler, including vc++ in normal non-standard preprocessor mode. I have no idea if any regression tests for msvc-14.1 are made with this /experimental:preprocessor switch, but I will wait for 'develop' to cycle through before merging to 'master' in Boost PP. My preprocessor tests show four failures with the new vc++ preprocessor. Two of the failures are based on the fact that the test code expects a macro called with the wrong number of arguments to produce a compiler error and not just a warning. But since I have been told, vis-a-vis the same situation occurring for the Oracle C ++ compiler, that compilers are allowed under the C++ standard to produce a warning and just "chug" on, even if producing macro output that is certainly not what the programmer intended, rather than produce a compilation error maybe I just need to eliminate those tests, as important as I think they are. The other two failures are with the BOOST_PP_ITERATE macro and corresponding structures. The new preprocessor also erroneously continues to give a number of argument mismatch warnings in cases where it does not really exist, similar to the non-standard preprocessor, but since it "chugs" on despite the false warnings it ends up producing the correct output anyway. I have already posted a bug report about the fact that the new preprocessor gives a warning and continues when a macro is called with the wrong number of arguments. The other problem with BOOST_PP_ITERATE will be harder to determine because the iterate mechanism in Boost PP is fairly complex and I will need to figure out what is causing it and reduce the failure to a much simpler form in order to report it. As far as the compiler warnings of the wrong number of arguments when they do not exist, again I will have to try and figure out why and report the bug(s) to Microsoft. If anyone wants to try this out on Boost PP 'develop' feel free to do so. You will need to invoke the msvc-14.1 toolset in Boost Build with the /experimental:preprocessor switch and you will need to upgrade VS2017 to 15.8 or above. You can tell whether you have succeeded invoking the Boost PP tests with the new preprocessor by looking at the run output of the config_info test. If the BOOST_PP_CONFIG_FLAGS() is 0x0001 it is the new preprocessor, else it is the default non-standard preprocessor (0x0004).

6 13

Invitation to join the C++ chat community!
by Vinnie Falco 23 Oct '18

23 Oct '18

All: Hi there. I would like to personally invite all of the Boost authors, participants on the mailing list, and interested parties to join the most popular C++ Slack workspace, where many lively technical discussions related to C++ and its ecosystem take place. There are channels for everyone, especially the #boost channel, but also channels for WG21 committee discussions such as #future_standard and #wg21. There's even an #sg14 ! You can learn more and request a free invitation here: <http://slack.cpp.al> This workspace is sponsored by the C++ Alliance, a non-profit organization which promotes and advances the C++ language and provides educational resources. Find out more about the Alliance here: <http://cpp.al> Regards

3 5

Development Calendar is empty
by James E. King III 23 Oct '18

23 Oct '18

When is the next freeze or release? https://www.boost.org/development/index.html - Jim

5 5

[histogram] Finalising version for submission
by Hans Dembinski 22 Oct '18

22 Oct '18

Hi all, I have a general question regarding the submission process on how to deal with extensions of the library. I am currently working on the points raised in the review. Clearly, the bugs need to be fixed and the documentation improved where it was lacking. So the procedure is clear in that regard, but the final version to be included in Boost will also have more features, the main ones are: - support for profiles and in general arbitrary accumulators as bin "counter" types - in particular any Boost.Accumulator - allow arbitrary metadata (or no metadata at all) to be associated with the builtin axes types, instead of just supporting a string label (the metadata type will be a template parameter) - use axis types through a traits-interface to make adding custom axis types really easy (a minimal axis only needs to implement `int operator()(something) const` and `unsigned size() const`, everything else is optional) - use storage types through a traits-interface to allow arbitrary STL and Boost containers as storage backends - add a support library for typical calculations done with histograms, like reducing a high-dimensional histogram to a lower-dimensional histogram, shrink an axis, etc - growing axes that increase the number of bins while the histogram is filled I started working on these features and switching to C++14 would simplify the implementation a lot, thanks to generic lambdas and return type deduction. So I would like to raise the requirement for the final library from C++11 to C++14. Since these are substantial changes, is another formal review of the final version required? In any case, I will request informal feedback on the final version on the list before histogram is released with Boost for the first time. Best regards, Hans

5 10