Boost logo

Boost :

Subject: [boost] Boost CMake support - Request for Comment
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-10-15 09:15:44

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Robert Ramey via Boost
> Sent: Monday, October 1, 2018 7:07 PM
> [...]
> Scope, Requirements and Features
> ================================
> We presume that submissions will fulfill the applicable requirements of
> any boost submission. In addition we would like to see the following
> addressed.

I'll start with the points I can answer (relatively) short and follow up
with another email for the rest.

> Library Build
> -------------
> “Effective CMake" -
> Recommends that all libraries - including header only libraries have a
> CMakeList.txt file. What should this include for Boost Libraries?

[See next email]

> Library Test
> ------------
> Should facilities for "testing" be only done by developers? or should
> users who acquire library packages also be able to test libraries.
> Should CMake testing results posting be used - CDASH?
> Should we just skip the issue of Library Testing and continue to depend
> on Boost Build.

I (a user) would very much like to be able to run boost tests locally, to make
sure it works as expected with the specific set of compiler and linker flags
chosen for my project. Personally, I don't need to be able to run all boost
library unit tests with a single" ctest . <some_parameter>" command, but for
release management that might be desirable.

I guess CDASH would be nice, but that is mainly a question for whoever is in
charge of the current testing infrastructure.

> Library Packaging
> -----------------
> Is the library packaging facility provide by CMake - CPACK - useful to
> boost. Should boost libraries be updated to support it?

If I want to use a boost package, I'd use a package manager (vcpkg, conan,
apt, brew ...) for that. Unless using CPACK significantly simplifies
packaging boost for those package managers, I don't think that would be an

> Dependencies
> ------------
> If the above is implemented, can we depend upon CMake to handle library
> dependencies? Or does some special functionality
> Do circular dependencies constitute a problem?

CMake can handle circular dependencies. I think the main questions is how
a cmake library should find its dependencies. I.e.


Should be the universal default (of course you can pick another naming convention),
but there are different possible ways how those targets could be found if they are
not generated by the same (super-) project:
- should each project do its own find_package ...?
- Should the user do this centrally?
- Should boost somehow stick to find_package(BOOST COMPONETS x,y,z) or
  rather find_package(boost_x), find_package(boost_y) ..?
- Should there be a single find_package that pulls in all available header only
- Also, should a library first check if a target is already available before
  calling find_package?

Not saying I find all of these choices reasonable. Just that there are different
possibilities and if boost absolutely wants or doesn't want to support one of
those it should probably be part of the requirements.

> Modularity
> ----------
> Currently boost is organized as a tightly integrated group of
> libraries. This organization manifests itself in a number of ways.
> We have a Boost "super project" in github. Boost libraries are "sub
> projects" of this super project. This known structure is exploited by
> and depended upon by boost tools. Should CMake support continue this
> policy/design.
> We distribute boost as "super project". Should we continue to do this
> or distribute libraries on a library by library basis. Does CMake/CPACK
> etc. make this "simple"?

For backwards compatibility there should still be a super project (and e.g.
the release should probably still provide the headers (or rather a link to
them) in one place.
However, I'd very much prefer if a common include directory was no longer
required by default.

> Documentation/testing
> ---------------------
> What support should be require for uses of Boost CMake implementation.
> Documentation, examples, templates for helping library developers. How
> should the CMake design/implementation be tested?
> Other considerations
> --------------------
> add your requirement/features here.
> Useful Resources
> ===============
> “Effective CMake" -

Also relevant even if not CMake specific:


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