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