Re: [boost] Boost CMake update

Subject: Re: [boost] Boost CMake update
From: paul (pfultz2_at_[hidden])
Date: 2017-10-02 16:59:04

On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:
> On 10/2/17 8:27 AM, paul via Boost wrote:
> > 
> > On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:
> > 
> > Thats what is being done.
> > 
> > > 
> > > 
> > > If that passes and is accepted
> > > 
> > > b) Apply to all the libraries desired.
> > No, apply to all libraries period, as authors of upstream libraries
> > shouldn't
> > hold back a library from moving to cmake.
> I think it would be unwise to presume that you can enforce this. 

I believe that is what the SC decision was about.

> Such 
> approaches have failed in the past. You would be better served by 
> focusing on creating a system whose benefits are sufficiently compelling 
> that the question of imposing the new system doesn't arise.  

One of the important use cases to support cmake in boost, is to move away from
problematic find modules for `find_package`. 

For example, you may want to support cmake in Boost.Serialization, but
Boost.Iterator does not desire to update to cmake. So now you will need to
create a Findboost_iterator.cmake module for Boost.Serialization. Not only
that, but any downstream users of Boost.Serialization will need to a copy of
the Findboost_iterator.cmake module. Now when the usage requirements for
Boost.Iterator changes all these modules will be wrong.

With the large number of libraries in boost, having boost half-implemented in
cmake will just be a nightmare for users. They will need to figure out which
libraries have cmake support and which ones need find modules. They will need
to fix the modules on their own when the usage requirements for non-cmake
libraries change. 

Also, a lot of the libraries are very intertwined, so its not really possible
to update to cmake piecewise. For example, to implement the build and tests in
cmake for Boost.Config, we need cmake support for tr1, core, type_traits, and
detail, which these libraries already depended on Boost.Config as well.

> To me this 
> is the main benefit of having such tooling ideas go through the boost 
> review process.

The system is already defined by cmake, adn BCM doesn't plan to change that..
The modules are just there to improve the cmake's workflow in the context of
boost.

.