Re: [boost] Strawman proposals for CMake support

Subject: Re: [boost] Strawman proposals for CMake support
From: Jens Weller (JensWeller_at_[hidden])
Date: 2017-07-21 13:18:12

> Gesendet: Mittwoch, 19. Juli 2017 um 03:09 Uhr
> Von: "Louis Dionne via Boost" <boost_at_[hidden]>
> An: boost_at_[hidden]
> Cc: "Louis Dionne" <ldionne.2_at_[hidden]>
> Betreff: [boost] Strawman proposals for CMake support
>
> 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:
> 
> (1) Users have a hard time integrating Boost into their build system,
>     which is CMake more often than not.
> 
> (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.
> 
> 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.
> 
> 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
> 
> I see the following disadvantages:
> - Boost's infrastructure could grow more complex as a result
> - Our build system would be less uniform
> - We would have to depend on all the build systems that we want
>   Boost libraries to be usable with
> 
> 
> My personal preference is towards the first option, since I
> think it would be simpler in the long term. I could certainly
> be convinced otherwise.
> 
> There are probably other ways we can solve problems (1) and (2)
> exposed above. There are also certainly advantages and
> disadvantages that I forgot to mention above. I'd love to get
> some feedback on those two approaches and see whether one of
> them (or something else completely) can get some consensus on
> this list.

Response to these ideas, but also on the whole plan. boost.build has made boost independent from 3rd party build systems, its historically grown.
Its not your workhorse, thats C++, boost.build is a good part of your infrastructure, kind of the roads for your workhorse.

Looking at the recent survey from JetBrains, the C++ community at large is using different roads today:
https://www.jetbrains.com/research/devecosystem-2017/cpp/

5% boost build, 34% CMake. CMake added server mode this year, driving adoption from the IDE field (think VS/QtCreator here) to CMake.
Its good to see boost adopting to this.

One way that hasn't been discussed so far afaik is, that CMake also provides generators for build systems. One could write a CMake generator as an Adaptor to boost.build.
This only could be done by boost, would ensure that the generated boost.build files have a certain standard, the current infrastructure would suddenly still be useful, even when new libraries don't come with author supported boost.build files, boost would be able to generate these through the provided CMake files.

This knowledge could be useful in the future to adopt other build systems such as Meson too.

This solution would serve your current, boost.build based user base, as none would have to convert to CMake, while boost it self would be able to add CMake support to its libraries, offering two build systems instead of one. The current infrastructure would not need to be rewritten and no one would have to reinvent the wheel very often...

thanks,

Jens Weller