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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk