Re: [boost] [1.41] boost-cmake leaving svn

Subject: Re: [boost] [1.41] boost-cmake leaving svn
From: Eric Niebler (eric_at_[hidden])
Date: 2009-10-15 09:47:03

troy d. straszheim wrote:
> Eric Niebler wrote:
>>
>> Not only is it disruptive, but it's against policy to commit directly
>> to release.
> 
> I know that, I was just trying to spin it.
> 
>> My opinion: the cmake build system should be like other parts of 
>> boost: polished, documented, tested, reviewed, accepted, merged to 
>> trunk and then to release, and actively maintained.
> 
> Please forgive me for saying this is a bit far-fetched.  If I propose a 
> library for inclusion and it gets rejected, fine, I still have a 
> library.  If I propose a build system (arguably more work than a typical 
> library) and it gets rejected, I've got nothing.  

No, you've got what you have now: a separately maintained boost-cmake 
distribution. If boost-cmake were reviewed and accepted, we'd have 
working cmake support in trunk and release also.

Besides, I can't imagine a world where boost-cmake support is *not* 
accepted.

> A new library doesn't 
> typically require everybody to change the way they do business 
> throughout the entire release cycle, from development to testing, and 
> therefore doesn't encounter the inertia of the community.   

This issue has never been satisfactorily addressed. Ideally, we should 
not require each and every boost developer to make build changes in two 
places. IIUC, the way it works now is that the cmake team works to keep 
the boost-cmake in sync with "boost-bjam." You're saying that that is 
working for you and your users. I don't see why that model shouldn't 
continue to work once boost-cmake has been merged into trunk and release.

> For that 
> matter, I'm having trouble imagining how one would merge a build system 
> from trunk to release.  This is the same problem that provoked this 
> discussion.

Why should there be a problem? Changes to bjam are first made on trunk 
and then merged to release, aren't they? What makes cmake different? 
It's an honest question.

>> Distributing an experimental build system in an official boost release 
>> was probably a mistake.
> 
> Well we thought we would get some users, and we got lots of them on the 
> end-users' side, but it didn't catch on with boost developers as I'd 
> hoped.  C'est la vie.

You seem to be laying the blame for broken cmake support on trunk and 
release at the feet of all boost developers everywhere. I don't think 
that's fair.

> I think the better way is:
> 
> * A few notes in Getting Started with pointers to the cmake stuff
> * One root CMakeLists.txt that just prints a message on where to get 
> boost-cmake
> * A link to some boost-cmake tarball area alongside the standard boost 
> tarballs.
> 
> That's the new proposal.

That could certainly work, but I still don't see why that is better. 
It's not less work, is it?

>> In that light, I must reluctantly agree that removing cmake from trunk 
>> and release is probably the right thing. Beman?
> 
> I doubt that it is necessary to agree at this point.  That stuff either 
> comes out of release or goes out broken.

Fair enough.

>> My worry is that as a side project, the cmake build system will get 
>> less use and less attention. It's been 2 years since the cmake effort
>> began, and where are we?
> 
> I don't see it that way.  We have 115 people on the boost-cmake list, 
> and a bunch of them were really helpful (thanks guys) in tuning up the 
> build for 1.40.0, and we'll do it again in a few weeks for 1.41.0. 
> Participation has been signficantly wider than when it was just Doug and 
> I.   There are docs, happy users, all that stuff.

Excellent! Glad to hear it.

>> I *really* want our users to have a standard option for building boost 
>> that integrates well with their chosen build environment.
> 
> They've got that.  It's done.

"Done" is a matter of perspective. In my dream world -- and unless I'm 
convinced otherwise -- it's done when it's merged to release.

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