troy d. straszheim <troy <at> resophonic.com> writes:
JOAQUIN M. LOPEZ MUÑOZ wrote:
Unless fixed, this is going to pop up again when the release manager prepares for 1.41.
This should be fixed in r56113, apologies about this and thanks for the notice.
Thank you for taking care.
I suppose there is some question whether it makes sense to keep this stuff in release/trunk or not, as it is apparently only used by end users and packagers; I take no pleasure in making the release process more difficult than it is;
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.
there is no point in maintaining cmakefiles on the trunk if they are not used by people working on/against the trunk; the 1.40 release didn't work out of the box, the patched 'cmakeable' 1.40 distribution is elsewhere.
I guess what's caused that problem is that CMake-stuff is not being automatically tested like the rest of material in Boost. If you manage to get a toolset to build with CMake rather than the standard Boost.Build, the CMake material would be as easily maintainable as any other Boost feature. Whether it has to be you or the authors who respond to failures, this is probably another matter. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo