Boost logo

Boost :

Subject: Re: [boost] Proposal for moving Boost to CMake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-18 21:15:14

> On Jun 18, 2017, at 2:05 PM, Louis Dionne via Boost <boost_at_[hidden]> wrote:
> Boost - Dev mailing list wrote
>> Howdy all,
>> This is a request for comments on a possible path for migrating Boost's
>> build system to CMake. [...]
> FWIW, I support this (or something very similar). Reading some of the
> discussions in this thread, it seems like people are getting caught into the
> trap of discussing the specifics of how we would implement a proper
> CMakeLists.txt file and so on. I think this is completely missing the point.
> What we need is to acknowledge that the current situation of supporting
> Boost.Build only is a major pain for our users since they (1) most likely
> don't use it in house, (2) don't know it, (3) don't want to learn it, and
> (4) have to deal with it whether they like it or not. If you go into the
> wild, you'll find
> - people that don't use Boost because it's too hard to build or integrate
> into their build system
> - people that only use the header-only libraries because they don't have to
> build them and/or because the integration is as simple as changing a header
> path
> - people that build properly but are tired of maintaining their bridge
> between Boost.Build and their own system
> This, I think is our real problem. The discussion is not about whether it's
> better for Boost library developers to use Boost.Build, CMake, or Bazel for
> that matter. It's about what's best our users, who GREATLY outnumber us. And
> given that CMake is the de-facto standard, the best way to help our users is
> to provide easy integration of Boost with that build system (however that
> happens).
> It is also worth noting that people on this list that oppose vocally are
> Boost library developers or folks with deep involvement/knowledge of
> Boost.Build, which is a very small minority. This has become clear through
> years of anecdotal evidence (such as speaking to people at conferences).
> Based on this and previous failed attempts, I think it is unlikely that
> we'll be able to make a decision based solely on discussion on this list,
> and my opinion is that a top-down decision is required to make something
> (anything) happen, like for the Git modularization.
> That being said, I would like to propose an alternative route that is softer
> than David's to see what people think. I still think that David's proposal
> is better, but if that was uncontroversial enough, perhaps this could get
> the ball rolling and we could go from there (and provide some relief to our
> users in the meantime).
> The proposal is to add to the Boost library guidelines the requirement that
> a XYZConfig.cmake module be provided with the installation of any Boost.XYZ
> library.

Or rather `boost_xyz-config.cmake` for each Boost.Xyz. The reason for this is:

* The `-config.cmake` is case-insensitive
* it matches the library name(ie find_package(boost_system) and find_library(LIB boost_system))
* It follows the boost guildelines to have all files be lowercase

> This module would simply export the proper CMake targets, which
> would solve the problem of integrating Boost with a CMake-based build system
> and would remove the need for the custom FindBoost support in CMake. This
> would not make Boost easier to build, but once built and installed, it would
> at least be trivial to use _properly_ from a CMake project. This does not
> require changing the build system of existing libraries to CMake.

Although I am not following the proposal. Are you suggesting that the Boost.Build generate these files? Or that we move to cmake to build and test, and we require the libraries to install the config files?

> Regards,
> Louis
> --
> View this message in context:
> Sent from the Boost - Dev mailing list archive at
> _______________________________________________
> Unsubscribe & other changes:

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