- Boost - lists.preview.boost.org

Re: [boost] [release] Master branch is now open for bug fixes
by Christophe Henry 25 Mar '24

25 Mar '24

Hi Marshall, I would like to merge in MSM this bugfix (2 missing includes): compile break in 1.85.0.beta1 when using favor_compile_time · Issue #70 · boostorg/msm (github.com) <https://github.com/boostorg/msm/issues/70> and this doc fix: Boost 1.85.0: Backend Dokumentation · Issue #69 · boostorg/msm (github.com) <https://github.com/boostorg/msm/issues/69> PR: Feature/1.85 beta by henry-ch · Pull Request #71 · boostorg/msm (github.com) <https://github.com/boostorg/msm/pull/71> Develop builds and tests ok. Regards, Christophe

2 1

A proposal for a modern build-system
by Hassan Sajjad 25 Mar '24

25 Mar '24

Hi. Preface: C++20 modules and header-units are a great addition to C++. There are numerous benefits of these. One of them is a faster compilation. Conventional build-systems however are unable to benefit from C++20 modules or header-units. Boost current build-system b2 does not support C++20 modules or header-units. CMake does not support C++20 header-units https://gitlab.kitware.com/cmake/cmake/-/issues/25293. I developed the build-system HMake https://github.com/HassanSajjad-302/HMake. It is in C++ and MIT Licenced. It supports drop-in header-files to header-units replacement. While compilers support processing a header-file as header-unit, no other build-system supports this feature. With this I compiled SFML with C++20 header-units https://www.reddit.com/r/cpp/comments/1555g6b/hmake_build_system_02_compili…. In the post, I mentioned that 2-3.5x speed-up was achieved but I did some more testing recently and an even better speed-up of 2.7-4.7x was achieved i.e., the speed of header-units is further improving with recent iterations. Proposal: I want to propose my build-system HMake for boost. Besides its already state-of-the-art C++20 modules and header-units support, it will be the first to support https://lists.isocpp.org/sg15/2023/11/2106.php or https://lists.isocpp.org/sg15/2023/11/2146.php if any of this gets implemented. These papers present ideas for faster module adoption and avoiding redundant module compilations. These need support from build-system. This way boost could be a breeding ground for C++20 modules adoption. Also, I have good experience with boost's current build-system b2 as a good portion of HMake's current API is inspired by it. Timeframe: I will complete this proposal in 3 months. Deliverables: 1) 2-months: Boost basic configuration compiled with C++20 header-units. This is more of a lone sprint. 2) 3-months: All boost current configurations + new with header-units and modules + tests and examples. This will require more active involvement by the current maintainers. I will give weekly updates here and will make a video after 2 months presenting the progress made. This will be to help other contributors so they can ensure that their library is fully supported. Cost: Standard C++ Developer Compensation for 3 months (Negotiable). Payments are to be issued monthly. But you can back out at any point in case you are unsatisfied with development speed or direction. Impact: While I don't see any reason for it to be a flop, it is an engineering endeavor so there is some inherent risk. The best-case scenario is that it improves Boost usability and 2.5x compilation speed improvement starts a domino effect for HMake and C++20 header-units and modules adoption. Best, Hassan Sajjad

9 37

Boost::serialize: im doing an Windows MSVC to Linux GCC port and i have a linker error (with a small example)
by Dennis Luehring 25 Mar '24

25 Mar '24

im doing an Linux/GCC port of an huge ~1Mio LOC/15 years grown Windows/MSVC project - my first step was switching over to CMake replacing the Studio-Solution file and in around 2.5 weeks i went from a hell lot of compile errors down to full compilation and nearly full linking - happy state so far :) but i stumbled over an linking problem using Boost::serialize with template types (in static libs and hundreds of them in this project) the code compiles and links with MSVC but not with GCC/Clang ld/lld/mold under Linux tested with Boost 1.84.0 - needs Boost::serialization ---- /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/linux_link_error_test.dir/main.cpp.o: in function `boost::archive::detail::iserializer<boost::archive::text_iarchive, MyType<double, 2ul> >::version() const': main.cpp:(.text._ZNK5boost7archive6detail11iserializerINS0_13text_iarchiveE6MyTypeIdLm2EEE7versionEv[_ZNK5boost7archive6detail11iserializerINS0_13text_iarchiveE6MyTypeIdLm2EEE7versionEv]+0x15): undefined reference to `boost::serialization::version<MyType<double, 2ul> >::value' ---- nm -C shows that the symbol 'boost::serialization::version<MyType<double, 2ul> >::value' is 'U' undefined in the the lib but i don't understand why the linker is looking for this header-only version function - and what MSVC is doing different to accept it as is i reduced the big scenario down to a more or less trivial sample to show the effect loading a dummy type "MyType" it compiles and links with MSVC but GCC gives me the linker error https://github.com/LowLevelMahn/linux_link_error | | build.txt | CMakeLists.txt | +---linux_link_error_lib <-- a static lib with the serializable 'MyType' | CMakeLists.txt | MyType.hpp <-- definition of the dummy type | serialize_MyType.hpp <-- definition of the boost serialization routines | test.cpp <-- dummy code for the static lib | \--linux_link_error_test <-- console app using MyType serialization CMakeLists.txt main.cpp the structure of the sample project, static-library, using different headers for type-definition and its serialize routines is intentionaly like in the original project - so i can maybe easily adapt a solution to my real project, i hope the sample is bare enough :) how to build: mkdir linux_link_error_dev cd linux_link_error_dev git clone https://github.com/LowLevelMahn/linux_link_error.git mkdir _build cd _build # Windows/MSVC cmake -G "Visual Studio 17 2022" -A x64 -DCMAKE_PREFIX_PATH=[boost-path]\lib\cmake ..\linux_link_error # Linux/gcc cmake -DCMAKE_PREFIX_PATH=[boost-path]/lib/cmake ../linux_link_error #or without prefix path if boost is installed as package in your distro cmake ../linux_link_error cmake --build . result: builds on windows on linux with gcc i get the linker error from above my system: recent Tumbleweed SUSE gcc 13.2.1 clang 18.1.1 ld: 2.42.0 lld: 18.1.1 mold: 2.30.0 my boost build: wget https://boostorg.jfrog.io/artifactory/main/release/1.84.0/source/boost_1_84… tar -xf boost_1_84_0.tar.bz2 cd boost_1_84_0 ./bootstrap.sh --prefix=/home/testing/boost_1_84_0_install ./b2 install it could be that all the MSVC magic/micro compiler/linker differences i've learned in the last years don't let me see the truth :(

1 1

Boost BCP tool is abandoned.
by René Ferdinand Rivera Morell 24 Mar '24

24 Mar '24

While making changes to update the various tools I found that the BCP tool is abandoned. As in it hasn't been updated for a couple of years. And because of changes to Boost.Filsystem no longer builds. And since no one has complained about it not building, I'm guessing no one uses it. There's two choices to deal with this: 1. Find someone to maintain it. 2. Delete it and move on with other more important things. I favor #2. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

4 3

Linker errors under Linux on using locale in a tiny example - using my own boost build
by Dennis Luehring 21 Mar '24

21 Mar '24

i can't built a simple locale from_utf using example with my own build boost 1.84.0 [system] SUSE Tumbleweed gcc (SUSE Linux) 13.2.1 20240206 [revision 67ac78caf31f7cb3202177e6428a46d829b70f23] [boost build] using https://boostorg.jfrog.io/artifactory/main/release/1.84.0/source/boost_1_84… tar -xf boost_1_84_0.tar.bz2 cd boost_1_84_0 ./bootstrap.sh --prefix=/home/test/boost_1_84_0_install ./b2 install ---- [CMakeLists.txt] cmake_minimum_required (VERSION 3.14) project (MyTest) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) list(APPEND CMAKE_PREFIX_PATH "/home/test/boost_1_84_0_install/lib/cmake") find_package( Boost REQUIRED COMPONENTS locale ) add_executable( my_test main.cpp) target_link_libraries( my_test PRIVATE Boost::boost ) ---- [main.cpp] #include <boost/locale.hpp> int main() { auto x = boost::locale::conv::from_utf( "blun", "ISO-8859-1" ); return 0; } ---- build: _build>cmake ../MyTest _build>make [ 50%] Building CXX object CMakeFiles/my_test.dir/main.cpp.o [100%] Linking CXX executable my_test /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/my_test.dir/main.cpp.o: in function `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > boost::locale::conv::from_utf<char>(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::locale::conv::method_type)': main.cpp:(.text._ZN5boost6locale4conv8from_utfIcEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKT_RKS8_NS1_11method_typeE[_ZN5boost6locale4conv8from_utfIcEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKT_RKS8_NS1_11method_typeE]+0x42): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > boost::locale::conv::from_utf<char>(char const*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::locale::conv::method_type)' collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/my_test.dir/build.make:97: my_test] Error 1 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/my_test.dir/all] Error 2 make: *** [Makefile:91: all] Error 2 any idea what is happening here?

3 4

Porting to Openvms
by Barrett Southworth 18 Mar '24

18 Mar '24

I see the source files for setting up config.hpp. But I don't see how to create source files for OpenVMS (the vms.hpp is really out of date). The compiler VSI CXX. Or any of the other options. Is there a guide for setting up the config that I'm missing? If not any suggestions for how to go about setting up those files?

2 2

release clang++ std=c++23/26 trunk version emit diagnostics errors on #include <boost/program_options.hpp>
by Bjørn Roald 17 Mar '24

17 Mar '24

https://gcc.godbolt.org/z/d3PTjdMhr this is fixed by changing suspect throw() declarations with BOOST_NOEXCEPT I have not checked rest of boost for diagnostics with this compiler, but my understanding is that throw() declarations are no longer part of the standard and compilers may emit diagnostics like this. Is there any reason, except for the work to be done, not to use BOOST_NOEXCEPT everywhere? — Bjørn

2 1

Social Media Guidelines
by Vinnie Falco 16 Mar '24

16 Mar '24

I guess I'll take a stab at offering a starting point for social media posting guidelines. When I had access to post to the Boost_Libraries account there were basically two kinds of posts. Official communications from the Developers, and unofficial but relevant announcements. The Developers are defined as the set of members of the boostorg GitHub organization who have the Owner role, plus any proxies they authorize. Official communications include: * When a review starts https://twitter.com/Boost_Libraries/status/1622664075217092609 * When review results are available https://twitter.com/Boost_Libraries/status/1768833941341896756 * When a Boost release is published (usually 3 a year): https://twitter.com/Boost_Libraries/status/1735542393229967849 * When a change in policy for the libraries happens: https://twitter.com/Boost_Libraries/status/1633484289693339648 Official communications are identifiable by the Boost logo watermark appearing at a prescribed location and size in the color Boost Mustard. Examples of unrelated but relevant announcements include: https://twitter.com/Boost_Libraries/status/1716891934986530946 https://twitter.com/Boost_Libraries/status/1748504615371334006 Unofficial posts should have images if possible, but never with a Boost logo watermark, to denote that the post does not presume to speak for or have an association with the Developers. Anyway, these are the set of rules I informally invented when I had posting privileges to Boost_Libraries. I always checked with other developers before posting anything, especially for unofficial posts to ensure that the content was relevant to Boost in some fashion. This could be used as the starting point for explaining the guidelines for operating official Boost accounts. There is a page in the new site docs (a work in progress for sure) which is intended to capture these guidelines in a way that is easily understood by readers: https://www.boost.io/doc/contributor-guide/tweeting.html Disclaimer: That page is probably not be up to date, and is not the product of a consensus-driven process. But it can be, someone just needs to volunteer to do the work. Thanks

1 0

Review schedule update
by Mateusz Loskot 16 Mar '24

16 Mar '24

Folks, I have just updated the review schedule with status of the reviewed libraries as well as Boost versions releasing the new libraries. I'll appreciate if authors of the libraries (from STLInterfaces onwards) could verify if I've got their release version right. p.s. thanks to Christopher Kormanyos for nudging me about the update. Best regards, -- Mateusz Łoskot - on behalf of the Review Wizards Team

2 3

Re: [boost] (Important) Boost Foundation meeting this Wednesday
by Louis Tatta 16 Mar '24

16 Mar '24

On Mon, Mar 11, 2024 at 12:23 PM David Sankel <camior(a)gmail.com> wrote: > Our monthly Boost Foundation meeting is this Wednesday at 3pm Eastern > (12pm Pacific). > To: Boost developer community and Boost Foundation Board Hi everyone, I write to address two important matters regarding recent events. First, upon reviewing my messages with David and conferring with Vinnie, I must apologize for a miscommunication. I did not realize that “copyright assignment” was a term of art which means to transfer all legal rights and title. I thought instead it meant that Boost Foundation would receive a license to reproduce the logo without permission in referential contexts. Vinnie wasn’t involved in this so it is unfair to blame him; in fact, the task of this communication was delegated to me specifically because David suggested that dealing with someone else might be preferable to dealing with Vinnie. Second, as the agenda for the Boost Foundation board meeting occurring on March 13th includes a discussion of the new website, I would reiterate our proposed contribution to the developer community. A transfer of copyrights is not in line with Boost tradition, but it is still possible for us to have a healthy relationship. Thusly we repeat our previous offer: 1. The boost.org domain will point to The C++ Alliance servers running the new website, which we will operate and pay for. 2. Administrative access to the new cloud services will include Sam Darwin (CTO of C++ Alliance), plus anyone appointed by the developer community. 3. The new Boost logo (“B Mark”) will have its copyright and trademark retained by The C++ Alliance, and it will be published under a license which allows for irrevocable, permissionless reproduction in the context of referring to the Boost Libraries. The text for this is being prepared by our legal team, and it will be similar to the wording found under “Foundation name and C++ logo” here https://isocpp.org/home/terms-of-use. 4. Work on the website and documentation will continue in the repositories now under control of the developer community at https://github.com/boostorg/website-v2 and https://github.com/boostorg/website-v2-docs and licensed under the BSL. 5. If and when the developer community feels that the new website, infrastructure, or level of support received does not meet with expectations, the boost.org domain can be pointed away from The C++ Alliance servers. We believe this proposal is fair, generous, and respectful to tradition. It honors contributors by empowering them to continue their work, in a way that preserves the independence of the Boost project. Thank you for your consideration in this matter. Louis Tatta CEO, The C++ Alliance, Inc.

8 17