Re: [boost] Strawman proposals for CMake support

Subject: Re: [boost] Strawman proposals for CMake support
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-19 12:27:18

Hi Louis,

while (as should be obvious) I'm strongly favouring the second proposal
(if I had to pick between the two), there are nonetheless points I'd
like to add to the rest of the message. I hope that doesn't dilute the
rest of it.

On 18.07.2017 21:09, Louis Dionne via Boost wrote:
> Hi,
>
> I'd like to expose two strawman proposals for adding CMake support
> to Boost. Both proposals would solve the following problems, with
> different advantages and disadvantages:

I keep reading various "analyses" about where the supposed pain points
are with the current Boost infrastructure, and following that, what
requirements should be met by any future version. But all too often, the
discussion then jumps to solutions, without ever consolidating on the
problem analysis. At least it's my impression that there are multiple
"camps" of users all arguing from very different perspectives,
representing different "development cultures".

> (1) Users have a hard time integrating Boost into their build system,
>     which is CMake more often than not.

Here is one of the fault lines: what is meant by "integrating Boost" ?
Some have argued that it ought to be possible to actually build Boost as
part of another project (thus integrating means the build system. For
others, it merely means the ability to build their own project with
Boost as an external (precompiled) dependency. How frequent are these
two requests, and how important is it for Boost to meet them ?(2)
Prospective Boost developers are sometimes driven away from
>     submitting because they would have to learn Boost.Build, which
>     is not widely used and has a limited knowledge base.

I agree.

> FIRST PROPOSAL
> ==============
> The first proposal is to move completely to CMake and to render
> Boost.Build support optional. The possible rollout plan would
> look something like:
>
> 1. We start requiring that new libraries support both Boost.Build
>    and CMake.

(Why ? If you decide to move to CMake, why requiring new libraries to
support anything other than CMake ?)

>
> 2. We start adding CMake support to existing libraries.
>    This will take time.
> 2.1 We start moving our infrastructure to be CMake-based.
>
> 3. We release Boost with dual support for a while, letting time
>    for things to bake.
>
> 4. We remove the requirement that Boot libraries can be built
>    with B2. Libraries (existing and new ones) are free to provide
>    such support, but they are not required to.
>
> This would bring CMake to the status of "primary" build system
> for Boost. This could be based on Paul Fultz's work in progress
> at [1]. This has the following advantages (in the long term):
> - Less technical debt because we only have one "official" build
>   system to maintain.
> - The build system is uniform across all of Boost, which means
>   it's easier for folks to maintain it and understand it.
> - It gives maximal flexibility to CMake-based users.
>
> However, it has the following drawbacks:
> - We'll need to do a wholesale migration to build system XYZ when
>   CMake is not cool anymore.
> - It's harder to get buy-in from some developers that love
>   Boost.Build
>
>
> SECOND PROPOSAL
> ===============
> The second proposal is to make Boost into an almost build-system
> agnostic collection of libraries. Basically,
>
> 1. Provide CMake package config files for all Boost libraries so that
>    they can be used from CMake (either automatically, manually, or a
>    mixture of both). This could be based on Peter Dimov's work at [2]
>    (or [3], not sure which one is most current).
>
> 2. Make it possible to build CMake-based projects from Boost.Build, or
>    the other way around, or provide a build system agnostic script to
>    build all of Boost. This way, Boost libraries can decide whether
>    they want to support B2 or CMake.
>
> This has the following advantages:
> - Possibly easier to implement
> - We could possibly support other build systems too (e.g. if a
>   Boost author really wants to use scons for his/her library)
> - We don't have to do a wholesale move to XYZ when CMake is not
>   cool anymore

All true.

>
> I see the following disadvantages:
> - Boost's infrastructure could grow more complex as a result
> - Our build system would be less uniform

In fact, if we go to the extreme, there wouldn't be a single "boost
build system" any longer. There would be a standard (a set of
conventions) for

* naming generated files
* directory structure
* required documentation
* entry points to trigger a build / test run
* etc.

all to encapsulate the actual build process of individual libraries,
while still providing the same consistency to Boost users. (Note that
this does not in itself open the door for arbitrary build tools to be
used. That would be a separate, orthogonal discussion.)

> - We would have to depend on all the build systems that we want
>   Boost libraries to be usable with

Now this is quite fuzzy again. Your implied requirement seems to be that
every user may want to build boost, as a whole, and thus will need all
the tools. I think this is nuts.
The first problem is again that you think of Boost as a single entity.
While that has some appeal to some (for example for legal reasons), I
think technically we should really start thinking about Boost libraries
as independent components, so a "Boost user" really becomes a
"Boost.Compute" user or a "Boost.FileSystem" user, etc., which massively
reduces the problem.
Second, most "users" don't need to build the Boost library they are
using, or at least, they don't need to build it as an integral part of
whatever other project they are working on. So they could treat it the
same way as any other third-party dependency.
Thirdly, yes, if we allow different build tools to be used, it means
that those who want to build these libs will need to adapt. I simply
trust that the individual (Boost) library communities can figure out
much better what tools suite them best than what any top-down steering
committee could.

Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...