Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2017-06-18 19:05:18

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

Regards,
Louis

--
View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695623p4695717.html
Sent from the Boost - Dev mailing list archive at Nabble.com.