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