Boost logo

Boost :

Subject: Re: [boost] CMake, modular Boost, and other stories
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2019-04-23 19:34:06

On Tue, 23 Apr 2019 at 18:41, Peter Dimov via Boost <boost_at_[hidden]>

> It's been quiet lately, so it must be time for another CMake discussion.
> As you know, Boost 1.70 installs CMake configuration files on `b2
> install`,
> and we've started to receive feedback, some of which more interesting than
> what doesn't work.
> At present, `b2 install --with-filesystem` for example installs a
> configuration file boost_filesystem-config.cmake, which enables CMake
> users
> to issue the command `find_package(boost_filesystem)` and then use
> Boost.Filesystem. This mimics what an ordinary, independent library that
> happened to be called "boost_filesystem" would do.
> It also installs an umbrella BoostConfig.cmake file, which enables the
> alternative use of `find_package(Boost COMPONENTS filesystem)`, which
> treats
> Filesystem as a component of the package Boost, rather than as a
> standalone
> library. This is compatible with the existing, pre-1.70 use of
> FindBoost.cmake to locate Boost from CMake.
> Brad King (from Kitware, who should know) argues that installing separate
> configuration files for all the libraries is wrong. He says that the
> preferred practice is to only support the second use, with Boost as the
> package, and the libraries as components, not accessible as packages on
> their own. (The discussion is here:
> The reason I went with installing separate configuration files was that I
> expected that (a) this would be our preferred future approach when, or if,
> we switch to building with CMake and (b) even if not, this seemed like a
> step in the right, "modular", direction where libraries are treated as
> independent rather than parts of the monolithic package Boost.
> I'm having second thoughts though. It looks to me that Brad is right, and
> that the various library configuration files should be implementation
> details of a single Boost package (in the CMake sense) and not be
> user-visible. That is, only support
> find_package(Boost COMPONENTS filesystem)

^^ this is compatible with every existing c++ program that includes boost
via cmake

> and drop
> find_package(boost_filesystem)

^^ speaking as someone who has been a very active consumer of boost and
CMake for the past 6 years, in cross-platform environments, this will be a
package dependency management nightmare. Please do drop it.

In CMake, boost libraries are COMPONENTS of Boost. It's clean, teachable
and maintainable.

> Thoughts?
> _______________________________________________
> Unsubscribe & other changes:

Richard Hodges
office: +442032898513
home: +376841522
mobile: +376380212

Boost list run by bdawes at, gregod at, cpdaniel at, john at