On 2019-04-23 12:40 p.m., Peter Dimov via Boost wrote:

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: https://gitlab.kitware.com/cmake/cmake/issues/19186)

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)

and drop

   find_package(boost_filesystem)

Thoughts?

I don't quite understand how you frame the discussion. The fundamental question is not about how to make proper use of CMake idioms, but whether we consider Boost to be one project (with one package, etc.), or an umbrella organization that hosts multiple projects. And until we have figured that out we shouldn't even consider technical details such as how to spell `find_package()` invocations to find Boost libraries. And just to spell it out loud and clear: I'm very much in favour of the latter, i.e. Boost as an umbrella org. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On Tue, Apr 23, 2019 at 11:41 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:

It's been quiet lately, so it must be time for another CMake discussion.

It's not just a CMake discussion you are attempting. You are just using CMake as the hand-grenade ;-)

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)

and drop

find_package(boost_filesystem)

Thoughts?

I disagree. In my ideal world the "Boost" package wouldn't exist at all and you would only install/use/find the individual Boost libraries. Anything else is either living in the past or a convenient transitional method. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

On Tue, Apr 23, 2019, 12:41 PM Peter Dimov via Boost wrote:

That is, only support

find_package(Boost COMPONENTS filesystem)

and drop

find_package(boost_filesystem)

Thoughts?

+1. Aside from the other benefits mentioned: - for better or worse this is the already established Boost CMake user API. If we make a second, competing API both will need to be effectively supported forever. Doesn't seem worth it. - while some have proposed that Boost become simply an award we attach to libraries that are good enough, that certainly isn't what we have now or will have in the foreseeable future. Boost is a thing you can download, install, and use. Components are a great fit for Boost.