Re: [boost] [cmake] revision 50756 failed to merge some file properties

Subject: Re: [boost] [cmake] revision 50756 failed to merge some file properties
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-09-09 08:47:49

joaquin_at_[hidden] wrote:

> troy d. straszheim escribió:
>> Joaquin M Lopez Munoz wrote:
>>   
>>> IMHO if some specific material (CMake stuff in this case)
>>> is going to be delivered, then it *has* to be deployed
>>> and maintained in trunk just as anything else; this particular
>>> quirk was just that, a quirk, I wouldn't extract far-fetched
>>> consequences from it.
>>>     
>>
>>  From my perspective, it isn't a quirk;  When 1.41 time rolls around,
>> it will make sense to tune up the cmakefiles for release, and it will
>> still not make sense to tune up the cmakefiles on the trunk, where noone
>> uses them.  I'm not about to ask library authors to maintain two build
>> systems, nor to ask them to switch to cmake;  however I think the
>> cmakeable distributions are useful to a certain group, and it is easy
>> and efficient to prepare these asynchronously.
>>   
> 
> Would it be possible to set up a regression runner that uses CMake
> instead of Boost.Build
> so that problems with CMake are treated the same way as "regular" problems?

Why should this be the case? CMake is experimental, and it seems wrong to promote
problems with experimental anything to regular problems. I think we also have SCons setup
for Boost -- should that be also regression tested, and problems treated as regular?

- Volodya