Am 09.12.22 um 05:41 schrieb Mojca Miklavec via Boost:

Boost is only usable to me when it contains CMake support and I cannot test the above tarballs which completely lack it.

You need to install Boost with the official workflow (bootstrap and b2) which will generate CMake config files consumeable via `find_package` Not sure about the reason we don't use tags for RCs though.

On Mon, Dec 12, 2022 at 8:50 AM Mojca Miklavec via Boost wrote:

On Fri, 9 Dec 2022 at 09:57, Alexander Grund via Boost wrote:

...

Am 09.12.22 um 05:41 schrieb Mojca Miklavec via Boost:

...

Boost is only usable to me when it contains CMake support and I cannot test the above tarballs which completely lack it.

You need to install Boost with the official workflow (bootstrap and b2) which will generate CMake config files consumeable via `find_package`

The thing is ... is there an easy way to replace something like

set(BOOST_VERSION_SOURCE 1.81.0.beta1) FetchContent_Declare(boost URL https://github.com/boostorg/boost/releases/download/boost-${BOOST_VERSION_SOURCE}/boost-${BOOST_VERSION_SOURCE}.tar.xz) FetchContent_MakeAvailable(boost)

with the code that will run and compile bootstrap and b2 automatically and subsequently find the installed version, at least for some typical Linux and MSVC?

(I assume that I should be able to come up with some overly complex code to achieve that, but I would really like to avoid going that way.) Asking every user to install a gazillion of dependencies is a support nightmare. Having boost (and many other dependencies) compile automatically as part of the build process (when dependencies are not already found on the system) is an extremely helpful lifesaver.

This is what package managers were invented to solve. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

On Mon, 12 Dec 2022 at 15:58, René Ferdinand Rivera Morell wrote:

This is what package managers were invented to solve.

Which one? The first google hit for a package manager under Windows points to https://learn.microsoft.com/en-us/windows/package-manager/ and I don't seem to find boost there: https://github.com/microsoft/winget-pkgs/tree/master/manifests/b Sure, there's probably a package manager that provides boost, but maybe another dependency is missing there. Supporting novice users (as well as setting up CI jobs) on tons of operating systems is a nightmare as dependencies grow. And, in fact, I would dare to claim that CMake's FetchContent does in a way count to be "a package manager". Not a fully fledged one, but certainly an extremely useful one. On Mon, 12 Dec 2022 at 16:34, Дмитрий Архипов via Boost wrote:

I can't imagine package managers pulling and building Boost significantly slower than FetchContent does.

I first wanted to write a longer explanation, but thought that perhaps a live example would tell more than thousand words: https://github.com/mojca/cmake-troubleshooting-example/actions/runs/36810987... Results: - build from source: 1:48 for everything: to fetch boost, configure and build the project - install boost via vcpkg: 4:55 (+ whatever it takes to configure and build the project) - install boost via choco: 12:58 to install boost + 0:27 to configure and build the project - install via windows package manager: good luck ;), see above (I'll be grateful for hints about the best way to drop the time even lower. Maybe simply unzipping official windows builds ...) Plus whatever it takes to (learn how to) install the package manager first. (OK, vcpkg is a tiny bit biased. The list above fetches slightly more dependencies than the minimal example needs, but it fetches the real list that I need for a project. For choco I have no choice.) On Ubuntu it's a matter of a couple of seconds. But even on Ubuntu it's a problem that older versions don't provide a sufficiently recent version, so in many cases it needs to be installed "manually" as well. Reasons for longer build times: 1. vcpkg has to build everything from source, and it has to build full package dependencies even when the code itself doesn't need any of those recursive dependencies. 2. choco needs to install absolutely everything, and then I suspect that they might be checksumming files or doing some other magic that makes the installation of existing binaries (with no compilation) painfully, painfully slow.

That being said, you usually won't be able to install a Boost *release candidate* with a package manager.

True. But also: it's both heavily non-trivial to handle if one wants a project to be easy to build for novice users across a wide range of operating systems and compilers. Bottomline: having a CMake-compliant source version of Boost is still extremely, extremely useful. Mojca

On Mon, Dec 12, 2022 at 5:03 PM Mojca Miklavec via Boost wrote:

...

Once you do figure out how to get Boost 1.81 RC1 (or the release) installed please have a look at Boost.URL, a new library! Check out this BEAUTIFUL Reference Card: https://www.boost.org/doc/libs/master/libs/url/doc/html/url/ref/helpcard.htm... Full documentation here: https://www.boost.org/doc/libs/master/libs/url/doc/html/index.html Thanks!

On Dec 8, 2022, at 8:41 PM, Mojca Miklavec wrote:

On Thu, 8 Dec 2022 at 16:25, Marshall Clow via Boost wrote:

...

The first release candidates for the 1.81.0 release are now available at: https://boostorg.jfrog.io/artifactory/main/release/1.81.0/source/

The SHA256 checksums are as follows:

Why is there no tag/release at GitHub? https://github.com/boostorg/boost/tags https://github.com/boostorg/boost/releases

We don’t tag release candidates; only releases. — Marshall

On Dec 14, 2022, at 8:48 AM, Vinnie Falco wrote:

On Thu, Dec 8, 2022 at 7:25 AM Marshall Clow via Boost wrote:

...

...

No Asio release notes? This page looks mighty lean:

https://www.boost.org/users/history/version_1_81_0.html

Those are for the beta release. They will be updated with the notes for the actual release (hopefully later today; I’m working on it now) — Marshall