Re: [boost] [1.41] Build files locations, try 3

Subject: Re: [boost] [1.41] Build files locations, try 3
From: Eric Niebler (eric_at_[hidden])
Date: 2009-10-14 22:56:25

(cc'ing Beman because I'd like his input on this important release issue.)

troy d. straszheim wrote:
> Eric Niebler wrote:
>> troy d. straszheim wrote:
>>> Unless somebody takes over maintenance of cmake in SVN, I'm going to 
>>> remove cmake from trunk and release in the next couple of days, 
>>> before 1.41 gets frozen.  The reasoning was explained in previous 
>>> threads.  We cmakers are alive and well and have a good system for 
>>> creating cmakeable distributions in the weeks after each release.
>>
>> Troy, I must have missed those previous threads. Can you send a link 
>> or summarize the discussion for me? I'd like to know why we're 
>> regressing our cmake efforts on trunk and release.
> 
> This is really just a decoupling of unnecessarily coupled workflows. 
> Once a release of boost exists, it is then efficient to tune up the 
> cmakefiles for a boost-cmake release.
> 
> One can't, for instance, right now start committing to the cmakefiles on 
> the release branch (in anticipation of 1.41) because it is disruptive, 

Not only is it disruptive, but it's against policy to commit directly to 
release.

> setting off bells in an inspect script somewhere, I've done this several 
> times already.  AFAICT the fix is to maintain cmake on the trunk as 
> well, which increases the workload significantly for no gain (nobody 
> uses it there). Also, several bugs (cmake bugs) will likely come up in
> the weeks following the release, and with a separate release loop it is 
> easy to fix them and get patch releases out.

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. Distributing an experimental 
build system in an official boost release was probably a mistake. In 
that light, I must reluctantly agree that removing cmake from trunk and 
release is probably the right thing. Beman?

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 *really* want our users to have a standard option 
for building boost that integrates well with their chosen build 
environment. Until it is part of the official boost release, the cmake 
guys will be chasing tail-lights.

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