On Thu 15/10/09 07:00 , "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. 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. For that

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

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

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. the end-users' side, but it didn't catch on with boost developers as I'd hoped. C'est la vie. 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. 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.

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

Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Links: ------ [1] http://lists.boost.org/mailman/listinfo.cgi/boost