- Boost - lists.boost.org

Re: [boost] [async-mqtt5] Review questions
by Ruben Perez 18 Oct '24

18 Oct '24

(CC-ing the list) > > > > I haven't looked at the implementation yet, but I'm assuming that > > owning types are being used for a reason. > > You mean like ASIO buffers? Or vector? To std::move them around? I mean that the current interface is using std::string (owning) as the argument type for message payloads, which probably means that the implementation will std::move the supplied buffer, so the user doesn't need to keep it alive. My question was regarding the use of a character type (like std::string) vs a blob type (like std::vector<std::byte>), more than an owning vs. a non-woning type. Now that you've mentioned it, most Asio-based libraries require the user to keep the message payload alive for the duration of the operation, in an attempt to minimize copying. So I will add this to my list of questions for Ivica: is there a reason why you decided to use an owning type for the message payload? Regards, Ruben.

1 0

[release] Boost 1.87.0 closes for new libraries on 23-October
by Marshall Clow 16 Oct '24

16 Oct '24

As always, the calendar is at: https://www.boost.org/development/index.html — The release managers

1 0

Boost cross-compilation and testing (Linux -> Windows)
by Martin Vejbora 16 Oct '24

16 Oct '24

Hello, we're working on a new target for MinGW compiler, we're intending to have a cross-compiler from Linux Arm64 to Windows Arm64. We want to have Boost library as a benchmark of how complete our C++ compiler is and gradually improve it to support more features. I'm struggling though to get the cross-compilation and subsequent testing working. 1) I'm having troubles to set up cross-building of Boost with MinGW (even standard MinGW from package manager Linux x64 -> Windows x64). I'm getting errors while building Context, Process and Stacktrace modules. (I added to the respective error messages to the end of the email or full logs can be found here: https://github.com/user-attachments/files/17133738/x64_boost_build.log) My build commands: git clone --recursive https://github.com/boostorg/boost.git boost-build cd boost-build git checkout develop git submodule update --init --recursive echo "using gcc : : x86_64-w64-mingw32-g++ ;" > "user-config-x64.jam" ./bootstrap.sh ./b2 --user-config=./user-config-x64.jam --prefix=./boost-x64 --debug-configuration target-os=windows address-model=64 variant=debug install > x64_boost_build.log >From the error messages, it seems like I'm doing something essential wrong as for example Process module tries to build assembler for ELF format and SYSV ABI and not Window's PE format and MS ABI. 2) Subsequently, I didn't have much luck finding resources for cross-testing of Boost. Currently, I'm building and running tests in Ubuntu 22.04 in WSL on Windows machine. In general, this approach seems to work decently, Boost itself and its tests are built on Ubuntu as Windows binaries and when test executables are run, WSL automatically propagates it to run those executables on underlaying Windows. But a lot of tests are failing. I'm gradually investigating them and finding issues like missing dlls because b2 uses LD_LIBRARY_PATH and Windows doesn't understand it. I'm workarounding these issues but it's a slow process, so I wanted to ask, is the cross-testing of Boost library supported, are you aware of some examples where it's being used? Thank you and kind regards, Martin ------------------------------------------------------------------------------- a) Context errors: (similar also for jump_x86_64_sysv_elf_gas.S and ontop_x86_64_sysv_elf_gas.S) gcc.compile.asm bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/ target-os-windows/threadapi-win32/threading-multi/visibility-hidden/ asm/make_x86_64_sysv_elf_gas.o make_x86_64_sysv_elf_gas.S: Assembler messages: make_x86_64_sysv_elf_gas.S:47: Warning: .type pseudo-op used outside of .def/.endef: ignored. make_x86_64_sysv_elf_gas.S:47: Error: junk at end of line, first unrecognized character is `m' /home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:157: Warning: .size pseudo-op used outside of .def/.endef: ignored. /home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:157: Error: junk at end of line, first unrecognized character is `m' /home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:160: Error: junk at end of line, first unrecognized character is `-' "x86_64-w64-mingw32-g++" -x assembler-with-cpp -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_NO_LIB=1 -DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 -I"." -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/context/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/type_traits/include" -c -o "bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/target-os-windows/ threadapi-win32/threading-multi/visibility-hidden/asm/make_x86_64_sysv_elf_gas.o" "/home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S" ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/target-os-windows/ threadapi-win32/threading-multi/visibility-hidden/asm/make_x86_64_sysv_elf_gas.o... ------------------------------------------------------------------------------- b) Process errors: gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/ boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/ext/exe.o /home/vejby/boost-build/libs/process/src/ext/exe.cpp: In function ‘boost::filesystem::path boost::process::v2::ext::exe (HANDLE, boost::system::error_code&)’: /home/vejby/boost-build/libs/process/src/ext/exe.cpp:78:9: error: ‘QueryFullProcessImageNameW’ was not declared in this scope 78 | if (QueryFullProcessImageNameW(proc, 0, buffer, &size)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"." -I"/home/vejby/boost-build/libs/algorithm/include" -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/bind/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/detail/include" -I"/home/vejby/boost-build/libs/filesystem/include" -I"/home/vejby/boost-build/libs/function/include" -I"/home/vejby/boost-build/libs/function_types/include" -I"/home/vejby/boost-build/libs/fusion/include" -I"/home/vejby/boost-build/libs/iterator/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/optional/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/process/include" -I"/home/vejby/boost-build/libs/regex/include" -I"/home/vejby/boost-build/libs/scope/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/system/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/tuple/include" -I"/home/vejby/boost-build/libs/type_index/include" -I"/home/vejby/boost-build/libs/type_traits/include" -I"/home/vejby/boost-build/libs/unordered/include" -I"/home/vejby/boost-build/libs/variant2/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/ext/exe.o" "/home/vejby/boost-build/libs/process/src/ext/exe.cpp" ...failed gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/ext/exe.o... ------------------------------------------------------------------------------- gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/ boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/windows/default_launcher.o In file included from /home/vejby/boost-build/libs/process/src/windows/ default_launcher.cpp:16: ./boost/process/v2/windows/default_launcher.hpp:220:3: error: ‘STARTUPINFOEXW’ does not name a type; did you mean ‘STARTUPINFOW’? 220 | STARTUPINFOEXW startup_info{{sizeof(STARTUPINFOEXW), nullptr, nullptr, nullptr, | ^~~~~~~~~~~~~~ | STARTUPINFOW ./boost/process/v2/windows/default_launcher.hpp: In member function ‘boost::process::v2::windows::default_launcher::enable_init <Executor, Inits ...> boost::process::v2::windows::default_launcher:: operator()(Executor, boost::system::error_code&, const typename std::enable_if<( boost::asio::execution::is_executor<T>::value || boost::asio::is_executor<Executor>::value ), boost::filesystem::path>::type&, Args&&, Inits&& ...)’: ./boost/process/v2/windows/default_launcher.hpp:312:10: error: ‘startup_info’ was not declared in this scope 312 | &startup_info.StartupInfo, | ^~~~~~~~~~~~ /home/vejby/boost-build/libs/process/src/windows/default_launcher.cpp: In static member function ‘static std::size_t boost::process::v2::windows:: default_launcher::escape_argv_string(wchar_t*, std::size_t, boost::basic_string_view<wchar_t, std::char_traits<wchar_t> >)’: /home/vejby/boost-build/libs/process/src/windows/default_launcher.cpp:64:16: warning: unused variable ‘end’ [-Wunused-variable] 64 | const auto end = itr + sz; | ^~~ "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"." -I"/home/vejby/boost-build/libs/algorithm/include" -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/bind/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/detail/include" -I"/home/vejby/boost-build/libs/filesystem/include" -I"/home/vejby/boost-build/libs/function/include" -I"/home/vejby/boost-build/libs/function_types/include" -I"/home/vejby/boost-build/libs/fusion/include" -I"/home/vejby/boost-build/libs/iterator/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/optional/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/process/include" -I"/home/vejby/boost-build/libs/regex/include" -I"/home/vejby/boost-build/libs/scope/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/system/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/tuple/include" -I"/home/vejby/boost-build/libs/type_index/include" -I"/home/vejby/boost-build/libs/type_traits/include" -I"/home/vejby/boost-build/libs/unordered/include" -I"/home/vejby/boost-build/libs/variant2/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/windows/default_launcher.o" "/home/vejby/boost-build/libs/process/src/windows/default_launcher.cpp" ...failed gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/windows/default_launcher.o... ------------------------------------------------------------------------------- gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64 boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/environment.o In file included from ./boost/process/v2/default_launcher.hpp:17, from /home/vejby/boost-build/libs/process/src/environment.cpp:13: ./boost/process/v2/windows/default_launcher.hpp:220:3: error: ‘STARTUPINFOEXW’ does not name a type; did you mean ‘STARTUPINFOW’? 220 | STARTUPINFOEXW startup_info{{sizeof(STARTUPINFOEXW), nullptr, nullptr, nullptr, | ^~~~~~~~~~~~~~ | STARTUPINFOW ./boost/process/v2/windows/default_launcher.hpp: In member function ‘boost::process::v2::windows::default_launcher::enable_init<Executor, Inits ...> boost::process::v2::windows::default_launcher::operator()(Executor, boost::system::error_code&, const typename std::enable_if<( boost::asio::execution::is_executor<T>::value || boost::asio::is_executor<Executor>::value ), boost::filesystem::path>::type&, Args&&, Inits&& ...)’: ./boost/process/v2/windows/default_launcher.hpp:312:10: error: ‘startup_info’ was not declared in this scope 312 | &startup_info.StartupInfo, | ^~~~~~~~~~~~ "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"." -I"/home/vejby/boost-build/libs/algorithm/include" -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/bind/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/detail/include" -I"/home/vejby/boost-build/libs/filesystem/include" -I"/home/vejby/boost-build/libs/function/include" -I"/home/vejby/boost-build/libs/function_types/include" -I"/home/vejby/boost-build/libs/fusion/include" -I"/home/vejby/boost-build/libs/iterator/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/optional/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/process/include" -I"/home/vejby/boost-build/libs/regex/include" -I"/home/vejby/boost-build/libs/scope/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/system/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/tuple/include" -I"/home/vejby/boost-build/libs/type_index/include" -I"/home/vejby/boost-build/libs/type_traits/include" -I"/home/vejby/boost-build/libs/unordered/include" -I"/home/vejby/boost-build/libs/variant2/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/environment.o" "/home/vejby/boost-build/libs/process/src/environment.cpp" ...failed gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/environment.o... ------------------------------------------------------------------------------- c) Stacktrace error: gcc.compile.c++ bin.v2/libs/stacktrace/build/gcc-10/debug/x86_64/link-static/ target-os-windows/threadapi-win32/threading-multi/visibility-hidden/ from_exception.o /home/vejby/boost-build/libs/stacktrace/build/../src/from_exception.cpp:161:10: fatal error: dlfcn.h: No such file or directory 161 | #include <dlfcn.h> | ^~~~~~~~~ compilation terminated. "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -I"." -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/stacktrace/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/stacktrace/build/gcc-10/debug/x86_64/link-static/ target-os-windows/threadapi-win32/threading-multi/visibility-hidden/ from_exception.o" "/home/vejby/boost-build/libs/stacktrace/build/../src/from_exception.cpp" ...failed gcc.compile.c++ bin.v2/libs/stacktrace/build/gcc-10/debug/x86_64/link-static/target-os-windows/ threadapi-win32/threading-multi/visibility-hidden/from_exception.o...

3 4

[Boost][BGL] What are the correct vertex/edge index types?
by hermann＠stamm-wilbrandt.de 15 Oct '24

15 Oct '24

First I looked in graph/test. Most times int is used there, only once std::size_t: property< edge_index_t, int > Next I looked into graph/example, same picture there. Ok, I read that example and test might contain stuff that would not go into BGL code. So I looked into graph/include/boost/graph: pi@raspberrypi5:~/graph/include/boost/graph $ grep edge_index_t *.hpp | grep size_t directed_graph.hpp: typedef std::size_t edge_index_type; undirected_graph.hpp: typedef std::size_t edge_index_type; pi@raspberrypi5:~/graph/include/boost/graph $ grep edge_index_t *.hpp | grep unsigned directed_graph.hpp: typedef property< edge_index_t, unsigned, edge_property_type > undirected_graph.hpp: typedef property< edge_index_t, unsigned, edge_property_type > pi@raspberrypi5:~/graph/include/boost/graph $ grep edge_index_t *.hpp | grep int graphviz.hpp: property<edge_index_t, int> > pi@raspberrypi5:~/graph/include/boost/graph $ Only graphviz.hpp uses int. But directed and undirected graph use std::size_t as well as unsigned. There are systems when unsigned is smaller than std::size_t: https://en.cppreference.com/w/cpp/types/size_t 1) Shouldn't at least directed_graph.hpp and undirected_graph.hpp make consistent use of std::size_t then? 2) Shouldn't examples and tests be corrected, as their overly use of int for edge and vertex index types is misleading? Regards, Hermann.

2 1

deprecated: MPL, foreach, typeof, ratio, chrono, assign, more?
by Vinnie Falco 12 Oct '24

12 Oct '24

Should one or more of these libraries be marked as "deprecated" in their corresponding meta/libraries.json? Array Assign Chrono Compatibility compressed_pair enable_if ForEach functional mem_fn move MPL Ratio ResultOf Typeof The new website could use this information to annotate the library. We could add a "reason" field to libraries.json which is displayed on the site. The website could have a checkbox, "hide deprecated", enabled by default. We could show the reason for the deprecation. For example, that mp11 is a more modern and functional version of MPL. Or that ForEach is now a C++ language feature. The authors and maintainers of those libraries would need to opt-in to this, although we could have someone work up pull requests for some or all of those libraries. There might be more libraries that belong on the list, feel free to add. Another idea we might consider is to add a preprocessor deprecation warning, unless the user opts-in by defining BOOST_ALLOW_DEPRECATED or something. Before we do that though, we should ensure that no non-deprecated Boost libraries are using the above libraries. Thanks

20 51

Do Tools Need Formal Reviews?
by Vinnie Falco 10 Oct '24

10 Oct '24

Traditionally, tools used by authors and maintainers are quietly integrated with oversight from owners and release managers. Examples include saxon-he and docca (https://github.com/boostorg/docca) Recently there have been noises made expressing the desire for the formal review process to be applied to tools as well. The purpose of this post is to explain why this is a bad idea. There are two kinds of tools. External tools, brought into use by the project through the scripts which create the release, and internal tools which are in repositories added to the superproject. An example of an external tool is asciidoctor: https://asciidoctor.org/ This was quietly added and the command line tool is required to be installed in order to build a Boost release, as libraries such as Boost.mp11 or Boost.Unordered need it for producing their documentation. The Asciidoctor author provides the installation package and provides all support. The only documentation requirement for Boost libraries is that they render into HTML and that "b2 doc" works. A formal review to adopt "asciidoctor" as an available external tool could result in REJECT. This serves no useful purpose other than to make things more difficult for the author or maintainer. They can still use asciidoctor but would have to do it locally and commit the resulting HTML output to the repository, as the tool would not be available to the release process. This is objectively worse for everyone. An example of an internal tool is BoostLook: https://github.com/boostorg/boostlook This is a set of CSS files and Ruby scripts used by some libraries to style their Asciidoctor documentation. This was quietly added to the superproject as the release will need it for some of the libraries to build. Discussion with owners happened beforehand; the files for this tool were originally in the website-v2-docs repo (https://github.com/boostorg/website-v2-docs) but the objection was made (rightly so) that the website-v2-docs repo was too large to add to the superproject. Thus the files were put into their own small repository. A formal review to adopt BoostLook as an internal tool could result in a REJECT outcome. This serves no useful purpose other than to make things more difficult for maintainers. They would manually inline the boostlook files in their repository and be responsible for keeping it up to date (submodules in libraries are intentionally not cloned by the release script). Tools are not user-facing (where "user" is defined as a Boost user and not an author or maintainer). I've seen a lot of intellectual gymnastics trying to justify why tools are the equal of libraries but they fail in light of an obvious fact: tools no longer in use can be removed from the superproject without a tsunami of mailing list protest. It is true that tools which Boost end-users find useful can be adopted, but they do not come with the same promise of forever support the way that libraries do. They are only supported to the extent to which the Boost libraries need them. My maybe-unpopular opinion: b2 was correct to move to an independent repository, as this can come with implied lifetime support. There's a recurring theme: tools are not libraries, despite Robert Ramey's sincere efforts to formally review them as such. A tool is an administrative construct designed to facilitate the efforts of authors and maintainers when they wish to make use of the tool in more than one library. The use of the tool is still possible in a Boost library, without the tool becoming part of the superproject, yet with more effort and opportunity for mistakes. It is for this reason that we do not use the formal review process for tools, as rejecting a tool has only disadvantages for existing libraries. The very last thing we need to do now is to make things harder for authors and maintainers. An argument used to justify a formal review is that the resulting feedback can improve the tool. I agree that feedback is generally helpful, this is true even if there is no formal review. That is, there is no requirement for a formal review to be ongoing for someone to provide feedback. Just provide the feedback. Tools are boring, and unlikely to attract a significant number of review responses. Formal reviews of proposed internal tools which receive a very small number of reviewers do not signal strong consensus and I believe harm morale. The informal process used for oversight on the internal and external tools Boost uses to produce its releases has worked well, and no convincing rationale has been put forth for why it should change. We should not invoke the formal review process for tools. Thanks

8 11

Who can fix CI ?
by hermann＠stamm-wilbrandt.de 09 Oct '24

09 Oct '24

5 days ago I created my first PR: "new planar_vertex_six_coloring() algorithm with examples, tests and doc" https://github.com/boostorg/graph/pull/387 CI helped me to fix things I was responsible for. But after that CI still fails in code I am not responsible for. From release notes: https://www.boost.org/users/history/version_1_86_0.html "...Graph: Major update: C++14 is the new minimum standard; this was partly dictated by dependencies (at least to C++11) and partly by choice. If you require support for an older standard, please contact the maintainer. ..." Somebody (who?) forgot to tell CI that minimum requirement. Example error caused by this: gcc.compile.c++ ../../../bin.v2/libs/graph/test/gursoy_atun_layout_test.test/gcc-5/debug/x86_64/cxxstd-11-iso/threading-multi/visibility-hidden/gursoy_atun_layout_test.o In file included from ../../../boost/math/constants/constants.hpp:11:0, from ../../../boost/graph/topology.hpp:16, from ../../../boost/graph/gursoy_atun_layout.hpp:34, from gursoy_atun_layout_test.cpp:10: ../../../boost/math/tools/config.hpp:28:6: warning: #warning "Boost.Math requires C++14" [-Wcpp] # warning "Boost.Math requires C++14" ^ In file included from ../../../boost/math/tools/mp.hpp:15:0, from ../../../boost/math/policies/policy.hpp:11, from ../../../boost/math/constants/constants.hpp:16, from ../../../boost/graph/topology.hpp:16, from ../../../boost/graph/gursoy_atun_layout.hpp:34, from gursoy_atun_layout_test.cpp:10: ../../../boost/math/tools/type_traits.hpp:208:12: error: 'std::is_final' has not been declared using std::is_final; Since this is my first PR, will there be someone helping me in PR 387? Who owns CI? Can issues be created against CI? Or do I understand this completely wrong? Regards, Hermann.

2 2

(no subject)
by Christophe Henry 09 Oct '24

09 Oct '24

> Should one or more of these libraries be marked as "deprecated" in their > corresponding meta/libraries.json? > > Array > Assign > Chrono > Compatibility > compressed_pair > enable_if > ForEach > functional > mem_fn > move > MPL > Ratio > ResultOf > Typeof Yes for marking old libraries as obsolete, as it does not convey a "might be removed" tag. No for marking as deprecated for this reason. Yes for hiding obsolete libraries by default. Strong no for ever even thinking of removing a Boost library from 1.x. Strong no for marking as obsolete libraries which are using obsolete libraries in the implementation. This one would force me to drop parts of MSM which might be used in production code and I strongly oppose the idea. Christophe

7 20

Scheduled review of Decimal library
by Mateusz Loskot 08 Oct '24

08 Oct '24

Folks, On behalf of the Review Wizards Team, formal review of proposed Decimal library has now been scheduled: - https://github.com/boostorg/website/pull/878 The review details should be soon displayed on the website - https://www.boost.org/community/review_schedule.html Best regards, Mateusz Loskot

4 6

[context] Build error with context-impl
by Tim Haines 08 Oct '24

08 Oct '24

git -c advice.detachedHead=false clone --branch develop --single-branch --depth 1 https://github.com/boostorg/boost.git git -c advice.detachedHead=false submodule update --init --recursive ./bootstrap.sh --with-toolset=gcc --with-libraries=context ./b2 -d+2 --debug-configuration --debug-building --debug-generator headers context-impl=fcontext toolset=gcc cxxstd=20 notice: found boost-build.jam at /boostorg/boost-build.jam notice: loading B2 from /boostorg/tools/build/src/build-system.jam notice: Searching <redacted> for site-config configuration file 'site-config.jam'. notice: Configuration file 'site-config.jam' not found in <redacted>. notice: Searching <redacted> for user-config configuration file 'user-config.jam'. notice: Configuration file 'user-config.jam' not found in <redacted>. notice: Searching '.' for project-config configuration file 'project-config.jam'. notice: Loading project-config configuration file 'project-config.jam' from '.'. notice: will use 'g++' for gcc, condition <toolset>gcc-11 notice: using gcc libraries :: <toolset>gcc-11 :: /usr/bin /usr/lib /usr/lib32 /usr/lib64 notice: using gcc archiver :: <toolset>gcc-11 :: /usr/bin/ar warning: toolset gcc initialization: can not find tool windres warning: initialized from project-config.jam:12 notice: using rc compiler :: <toolset>gcc-11 :: /usr/bin/as /boostorg/tools/build/src/build/feature.jam:327: in validate-feature from module feature error: unknown feature "<context-impl>" /boostorg/tools/build/src/build/feature.jam:361: in expand-subfeatures-aux from module feature /boostorg/tools/build/src/build/feature.jam:422: in feature.expand-subfeatures from module feature /boostorg/tools/build/src/build/build-request.jam:20: in apply-to-property-set from module build-request (builtin):-1: in sequence.transform from module sequence /boostorg/tools/build/src/build/build-request.jam:32: in build-request.expand-no-defaults from module build-request /boostorg/tools/build/src/build-system.jam:778: in module scope from module build-system The feature is present: grep -A5 -n "feature.feature context-impl" libs/context/build/Jamfile.v2 52:feature.feature context-impl 53- : fcontext 54- ucontext 55- winfib 56- : propagated 57- composite I'm not familiar with the Jam DSL, so I'm not sure how to debug this further. Any advice is very welcome. Thanks. - Tim

2 2