Re: [boost] Whatever happend to migrating to CMake?

Subject: Re: [boost] Whatever happend to migrating to CMake?
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-04-12 12:09:52

On 4/11/16 11:10 PM, boost_at_[hidden] wrote:
> Somme time ago there seemed to be a serious effort to migrate Boost's
> build system to CMake.  While the documentation to this effort is still
> around,  it seems like the most recent activity dates to 2013.  I tried
> cloning the git repository at
> git clone http://github.com/boost-lib/boost.git modules, but it seems to
> be in an invalid state.
>
> Whatever happned to this project?  Was a decision made to stick to
> Boost.Build, or did the project peter out due to a lack of resources?  Is
> there interest in resurrecting the project?

I have a strong recollection of all this.  I'm not sure it's entirely 
accurate though.

There was a growing frustration with boost tools.  Building, 
maintaining, and supporting them required a lot of time.  The feeling 
was that weren't really doing a great job and that we should stick more 
to the stuff we're good at. The move to CMake was prposed and unveiled 
at BoostCon 2010 see: 
https://www.youtube.com/watch?v=oWHL8Y1WB9Y&index=6&list=PL_AKIMJc4roVg67uMOpzEpsYTolMvhxho 
and  https://github.com/boostcon/2010_presentations . There was a lot 
effort expended on this project by David Abrahams, Troy Strazeim and 
others.  They made a bunch of CMake components which worked as "add-ins" 
and got to the point where it could build all of boost and also I 
believe run all the tests.

The main idea was to change the boost development environment in a 
coordinated fashion.  This required a coordinated agreement and 
implementation and cutover.  With already a large number of libraries 
many of which didn't have the maintainers around, this proved to be an 
over ambitious task.  Basically it was a top-down effort which I'm 
personally always skeptical of.  Also, in response to this effort, the 
developers of boost build, made many efforts to address complaints about 
their produce and the whole effort fizzled out.  Finally, the skepticism 
of boost tools diminished with the wide success of quikbook.

So here we are.

I have a lot of complaints about boost build, but the developers of this 
product have a lot of respect from me.  They have hung in there an 
supported the effort and kept it working.  And it's a hard job.  I think 
that there is the view that if we only did ...  the problem would be 
solved - and that's not true.  It takes a continuing effort and only the 
developers of boost build have shown willing to accept and implement 
this view.

But I don't believe that the build tools have to be imposed from top and 
I don't believe that we have to exclude all other build/test 
alternatives. Each library author chooses his documentation system and 
each one chooses his test system, (Boost test, lightweight test, home 
brew, etc).  At times this is inconvenient, but it all in all it works 
pretty well.  I see no reason that library authors can't include a CMake 
directory in their libraries just as they have a build directory which 
supports boost build.  Users can select the one they want.  Boost build 
is requirement only because we want to support centralized monolithic 
testing.  Personally I would like to see us consider more distributed 
testing on an individual library basis - but that's another battle.

Robert Ramey