Re: [boost] CMake, modular Boost, and other stories

Subject: Re: [boost] CMake, modular Boost, and other stories
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2019-04-23 16:54:20

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...