Eric Niebler wrote:
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.
No, you've got what you have now: a separately maintained boost-cmake distribution. If boost-cmake were reviewed and accepted,
I think you have left out "polished, documented, tested" :-). One data point is transition to Boost.Build V2. I've spend a couple of months doing nothing but checking test results with V1 and V2 and making sure no problem is introduced by V2 itself. Even though the overall health of tests is better now, it seems reasonable to require that any alternative build system be similarly validated, and it will take similar amount of time. There's no magic way to do this overnight.
we'd have working cmake support in trunk and release also.
Besides, I can't imagine a world where boost-cmake support is *not* accepted.
I don't think there was any explicit decision to go with CMake -- even if we ignore Boost.Build for now, it's not clear that CMake is the best build system when compared with other alternatives. Therefore, any such discussion makes sense only if specific alternatives are ready -- as deemed by their authors. - Volodya