Re: [boost] Strawman proposals for CMake support

Subject: Re: [boost] Strawman proposals for CMake support
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2017-07-19 15:06:42

Le 19.07.17 à 16:39, paul via Boost a écrit :
> On Wed, 2017-07-19 at 14:37 +0200, Raffi Enficiaud via Boost wrote:
>> Le 19.07.17 à 03:09, Louis Dionne via Boost a écrit :
>>>
>>> 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
>> I personally believe that "anything" between the tool (cmake or
>> boost.build) and the developers should be avoided, whether it is a "good
>> idea" or not. So I will not be in favour of libraries such as, no
>> offense (**), BCM.
>
> The point of BCM is not to abstract away the tool(although some developers
> would like it to do that). Only to provide some functions for the boilerplate
> in involved in generation of package configuration, to help provide
> consistency with the testing, and provide support for documentation(ss cmake
> does not provide modules for boost documentation).

What I also really dislike in this approach is to have a very hard 
dependencies to whatever library that is lying in the superproject. My 
goal is to be able to distribute boost.test (library and tests parts) 
independently of boost as well.

Again that is to me the core of the problem: what CMake variables (or 
interface) is needed in individual libraries and in the superproject to 
have a decent global infrastructure?

>
>>
>> I would welcome a tool that dissects the Jamfiles and generates even a
>> rough/approximate CMakeLists.txt to start with.
>>
>> But I would "really" rather focus on the interface between the
>> superproject and the libraries, and among the libraries themselves to
>> cover the inner dependencies (flow of information basically: expected
>> targets, naming conventions, build variants, etc).
>
> I think any cmake should follow closely this:
>
> https://github.com/boost-cmake/boost
>

I will be honest: for the boost.test part, I will just rewrite 
everything in there. This is just an empty shell that is providing the 
very easy part, the tip of the iceberg.

And this is exactly my point that is not addressed in your reply: what 
is supposed to be in the CMakeLists.txt in terms of inter dependencies? 
For generating the doc? for testing and sharing their results? for being 
able to unit test the CMakeLists.txt itself?

I believe, and this is certainly better done in another thread, that the 
provided example does not address any of the main concerns, it just 
declares a target, and adds a couple of dependencies to its interface.

That is not enough.

Raffi