Stefan Seefeld wrote:
Vladimir Prus wrote:
I doubt Boost.Build can be decoupled much more. We have our own mailing list, our own issue tracker, our own webpage and our own releases.
The only coupling is that Boost.Build lives in Boost CVS, and I'm not sure if that's bad thing, or good thing.
Technically that may be correct. However, as a matter of fact, boost.build does get developed as part of boost. How long did it take to fix bbv2 bugs *after* boost was converted to use it ? And how much is the slip of the release due to problems in the infrastructure, as opposed to actual "C++ library code" ?
Nobody has the hard numbers. My gut feeling is that most of the slip is not due to infrastructure problems, but other factors. You should also keep in mind that of all Boost.Build work, only a fraction is Boost.Build core work. For example, funny naming rules for built libraries is not a core functionality of *any* build system. Likewise, Boost.Python support is not something you get for free when using make.
As a boost developer I'd rather not worry about infrastructure. At least not more than absolutely necessary.
That's a good abstract goal. Would you clarify when and how you was forced to "worry about infrastructure" and what concrete steps do you suggest to be taken? "be decoupled as much as possible" is not a concrete step as far as I'm concerned. - Volodya