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? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo