Boost logo

Boost :

Subject: Re: [boost] [1.41] boost-cmake leaving svn
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-10-15 10:07:56


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk