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

Subject: Re: [boost] [1.41] boost-cmake leaving svn
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-10-15 17:55:28

Eric Niebler wrote:
> troy d. straszheim wrote:
>> Eric Niebler wrote:
>>> 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.

The point was that the boost build system is only usable for building 
boost, unlike, say, a regex library.   You can't pack it up and take it 
elsewhere.

>> 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.

As I mentioned, we sync up with 'boost-bjam' after each release, when we 
know that everything builds.  This is efficient and serves us well.
Maintaining cmake on trunk and release would be vastly more effort, but 
if you had more people you could do it.

>> 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.

I think the crucial difference is that everybody maintains their own 
jamfiles.  If somebody merges to release without fixing their 
cmakefiles, and then modifies trunk, you could be hosed.  OTOH if 
everybody maintained their own cmakefiles, then I agree it could work 
the same way.

>>> 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 don't know where you get that.  I'm not blaming a bunch of people who 
just minded their own business.  I miscalculated, pushed for putting 
cmake on the trunk, I made the commits and I'm admitting 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.
> 

<shrug>

-t