Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: David Sankel (camior_at_[hidden])
Date: 2017-06-17 04:24:42

On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost <
boost_at_[hidden]> wrote:

> On 6/16/17 4:44 PM, David Sankel via Boost wrote:
>
>> * Boost sources would provide a compatible, drop-in replacement for the
>>    'FindBoost' module that is distributed with CMake. A CMake-based
>> application
>>    could point to it and, instead of using the system Boost libraries,
>> Boost
>>    targets would be built from source as part of the user build.
>>
>
> Hmmm would this be a FindBoost for the whole of Boost or for each
> particular library?  Who would re-write and maintain this FindBoost as the
> current one is not up the task.  Getting this right - or even better is not
> a trivial task.

I agree that this is a non-trivial task. The contract for FindBoost is
relatively straightforward. The implementation for the Boost-source version
of this library would look at the COMPONENTS argument and, based on that,
add_subdirectory the source for the particularly requested library. The
CMakeLists.txt file would be author maintained and provide its
corresponding target (e.g. boost::thread).

> I see this progressing with several milestones.
>>
>> 1. Release of a CMake-buildable Boost and the CMake conventions. In this
>> stage
>>     each Boost library can be built in isolation or with the entire
>> distribution
>>     and all the 'FindBoost' functionality mentioned above would be
>> incorporated.
>>
>
> 2. The unit tests for all Boost libraries are incorporated into CTest (the
>>     CMake unit test orchestration tools).
>>
>
> My experience is that many boost tests cannot be run with cmake.  For
> example, I cannot make a CTest test which will be successful on
> compile-fail. - Correction I can, but involves some gymnastics about
> re-invoking CMake and capturing the result and inverting it and ...

Thanks for pointing that out. With any build system switch, some things
will be easier and other things will be harder.

>
>
> 3. The Boost infrastructure is modified to use CTest for unit testing.
>>
>
> I don't think this would be necessary.

Perhaps not.

>
>
> 4. Unit testing functionality is removed from Boost.Build.
>>
>
> I don't think this is necessary either.
>

Likewise.

>
> 5. Boost.Build is removed.
>>
>
> If CMake is successful, boost build would die on it's own.  If you have to
> forcibly remove it, you've failed.

I see your point.

>
>
> Although there are many other great ideas floating around (e.g.
>> modularization
>> of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
>> CMakification of Boost because I think it is something that would have big
>> impact and is small enough to be doable.
>>
>
> The problem is that we have problems migrating to CMake BECAUSE we've got
> with the other stuff mentioned.
>
> Actually, I believe the real problem is the monolithic build/test design
> of boost libraries which inhibits evolution.  Boost Build developers have
> been very accommodating about adjusting to the particular features of
> different libraries.  This demonstrates good will, but has given use with a
> testing/deployment setup which is very complex.

Yeah, this is unfortunate, but I don't think this is unfix-able. One step
at a time. First, lets work on getting a decent CMake build. I would love
to have your support here Robert.