Boost logo

Boost :

From: pdimov_at_[hidden]
Date: 2021-07-16 08:22:39


Stefan Heinzmann wrote:
> Hi all,
>
> the recent activity regarding adding CMake support to some remaining
> libraries (many thanks go to Peter Dimov), encouraged me to try using
> FetchContent to integrate Boost into client projects. I'm sure many
> people are interested in such a possibility in order to reduce
> dependencies on the build environment.
>
> The brief result seems to be: It almost works. Enough to make it
> interesting.
>
> The reason for my message is to ask if this is supposed to work, i.e. if
> I am trying something that should work, either now or in the near
> future, or if it is a frivolous expectation on my part.

Yes, this is supposed to work. The fact that it doesn't (quite) is a bug
I need to fix.

At the moment you can get around the install errors by using

set(BOOST_EXCLUDE_LIBRARIES fiber serialization stacktrace test graph wave)

> 1. Optimized source download
>
> As listed, FetchContent pulls in the entire boost sources, regardless
> whether they're needed or not. This takes a significant amount of time
> and uses a lot of disk space for no benefit. Clearly, you would want to
> fetch only the sources you need, but there doesn't seem to be a good way
> to handle the dependencies between the various boost libraries.
>
> You could use the GIT_SUBMODULES option of FetchContent, but you'd need
> to list not only the libraries you directly use (Boost::format in my
> example above), but you also need to list the dependencies of those,
> which is tedious and brittle.

You can use `boostdep --brief format` to get the list of required
submodules.

> I imagine that this can be handled via a special tool that gets invoked
> as a PATCH_COMMAND, which is able to scan through the submodules that
> have been populated and populates all its dependencies. I haven't seen
> such a tool anywhere, but maybe somebody has got a solution already?

For CI, we use depinst.py (in tools/boostdep/depinst.)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk