Re: [boost] Modularized CMake-able Boost

Subject: Re: [boost] Modularized CMake-able Boost
From: Eric Niebler (eric_at_[hidden])
Date: 2010-12-27 14:55:45

On 12/27/2010 6:12 AM, Daniel Pfeifer wrote:
> Am Sonntag, den 26.12.2010, 23:35 -0500 schrieb Eric Niebler:
>> On 12/26/2010 11:17 PM, Rene Rivera wrote:
>>> The fact that "there aren't enough people" to make a cmake version
>>> possible should be an indication that it should be reconsidered. If it's
>>> not possible for *one* person, working part time, to create and maintain
>>> the build system, it's already failed.
>>
>> I don't think there is even one person actively working on it currently,
>> and there hasn't been for some time. We've all been distracted with
>> other things, including the guys from Kitware. IMO, we desperately need
>> a modularized-Boost-CMake-build "guy". Volunteers would be appreciated.
> 
> What exactly is the problem with CMake?

No problem at all.

> Could you describe the role of this "CMake-guy" in more detail?

There are several facets to this, and the first job is in figuring out
how far to go.

1) There already was CMake support in Boost but it was removed because
it was unmaintained. A "CMake-guy" could simply assume the
responsibility of maintaining this separate build system across all of
Boost. In this scenario, we leave the existing testing and release
procedures in place.

2) A more ambitious plan is to modularize boost, put each library into
its own git repository, and port *that* to CMake. I was working on that
until I got busy with other things. If someone were interesting in
running with this, I could help them get up to speed. The benefits of
this would be a very nimble and flexible Boost library development
ecosystem. The idea is very appealing to me.

3) Ryppl: this project had (2) as a sub-goal, but added a top-level tool
that took meta-data about project dependencies (in git repositories),
downloaded, built, installed, and tested everything. It was to be based
on git, CMake, and python packaging support. We got it to the point
where it could download, build, install and uninstall packages and
resolve some simple dependencies. It got hung up on resolving more
complicated dependencies, which is hard problem in the general case.
It's doable, but in the end, we just didn't have enough free time.

In all cases, there is also the issue of migration, how it effects
testing, release procedures, trac, the website, etc. etc. It's
acceptable so simply say it doesn't effect it at all and simply ship
CMake as an optional alternate build system. But a "CMake guy" would
have to commit long-term to maintaining it.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com