(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