June 2026 - Boost - lists.boost.org

Boost.Graph Documentation Got a Facelift: Ship it Or Not ?
by Arnaud Becheler 20 Jun '26

20 Jun '26

Dear Boostlings, Graphlings, We have taken a first step in modernizing the Boost.Graph documentation with a preview available here: https://491.graph.prtest3.cppalliance.org/graph/index.html . These first steps aim at solving low-hanging fruits and answering frequent complaints from users collected during the 2022 User Survey ( https://www.reddit.com/r/cpp/comments/vyt4t5/boostgraph_user_survey/ ) and BGL workshop 2026 ( https://github.com/boostorg/graph/discussions/466 ) - documentation hard to explore (no table of content, no search bar) - examples use old C++ and several don't even compile - outdated visual design We have been investing into several dimensions: - migrating the old pure html pages to asciidoc + antora - modern examples for each algorithm are compiled and run in CI, with output integrated in the documentation - higher scanability for algorithm complexity + where defined - a better landing for users not familiar with property maps The PR currently sits unmerged as we are trying to assess its viability. Important: - this is NOT the final vision, this is meant as a first important step. - the current scope is NOT a full rewrite/reorganization of each algorithm page (future work). - the current scope is a modernization of the documentation infrastructure. - we are just worried we may have made and missed important mistakes that should prevent the merge, so Jeremy Murphy (principal BGL maintainer) and I decided to poll around for general review and feeling. Question to the community: 1. Is the new documentation preview ( https://491.graph.prtest3.cppalliance.org/graph/index.html ) going in the right direction? 2. Is it better than the old documentation ( https://www.boost.org/doc/libs/1\_91\_0/libs/graph/doc/ )? 3. Would you want to see it merged in its current state or did you identify important mistakes we should absolutely fix before merge? Any general complaints not directly related to this PR scope is welcome and will be integrated in future work :) Thank you, Arno

4 10

100MB of Node.js modules shipped in the Boost release tarball
by Jonathan Wakely 19 Jun '26

19 Jun '26

There are 482 Node.js modules included in the boost-1_91_0.tar.bz2 tarball, totalling more than 100MB, which is nearly 10% of the size of the entire tarball. Some of these node modules contain known CVEs, e.g. Boost.Redis bundles axios-1.10.0 which is affected by several denial of service and information disclosure CVEs. This causes Boost to be flagged when scanning for software supply chain problems. Do these modules really need to be shipped in the release, or are they only used to generate the HTML docs and could be omitted from the release tarball? I tried removing libs/redis/doc/node_modules/* and building from the release tarball, and everything succeeded. That suggests they're not needed.

5 12

[Patch] modernize the codebase of Boost.Format which replace the old typdef with using alias
by frex_vk9 15 Jun '26

15 Jun '26

Hello. I saw that Boost require C++11 so i modernize the codebase of Boost.Format i replaced the old typedef with using alias for upgrade the lisibility for codebase in the future. and the test with b2 passed. Read the .patch file for review my commit. Regards. frex_vk9(a)proton.me

2 1

Vcpkg Binary Caching on GitHub Finally Made Easy
by Richard 14 Jun '26

14 Jun '26

Hi Boosters, <https://github.com/LegalizeAdulthood/vcpkg-github-cache> For a long time I've struggled with vcpkg binary caching on my github CI jobs. There's a variety of critical information buried deep across various documentation pages that all interact when you attempt to use binary caching on a github repository with public github runners and CI workflows. This weekend I finally got it all figured out and debugged for my public repositories and realized that the steps needed to make everything work are non-obvious and intricate. This is the perfect thing for packaging up as a github workflow action for reuse across repositories. This project consists of two actions: - one that does all the setup - one that analyzes your build log This gives you details on how your build interacted with vcpkg binary caching to report problems. Usually the build summary is all you need to understand the cache: cold seed, warm hit, partial hit, etc. Should you need to dig in deeper to debug a weird situation there are two knobs -- debug and trace -- that can give you enough detail on everything that happened so you can sort out problems without having to manually add logging to your workflow. It may still be necessary to manually adjust the permissions on individual packages that are shared across repositories on your account. Unfortunately there's no way to manipulate the permissions programmatically. The analyze action smooths this out by giving you a table of packages that had permission issues, with links to each package's permission page on github. From there you can quickly adjust permissions as needed without having to hunt through a long list of packages on your account. -- Richard -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

1 0