James Fowler <[EMAIL PROTECTED]> writes: > IMHO Boost has a third goal. Perhaps it came about implicitly, as > various contributers added bits and pieces to facilitate collaboration > on various projects, and was never really established as a significant > and fundamental goal on it's own. Maybe it was planned all along. > Since I missed most of the history, how it came to be is still a bit > opaque, but here's what I see now : that third goal is the creation of a > robust infrastructure to support the use and development of the Boost > library projects.
It's an ancillary goal, not the focus of Boost. It came about because infrastructure was needed. That may be part of the reason we haven't been giving it quite the attention neccessary. It is clearly crucial to do a first-class job with this stuff, or the rest will fail (or at least growth will cease). > The current realization of this goal is the "Boost Tools", including > the Boost build system, BoostBook, the regression testing process, > and so on. This goes beyond tools, actually. Boost has grown beyond our ability to manage it in the casual style and with the diffuse responsibilities that have succeeded up to this point. We have to re-examine how we run things, or the software (and hardware) infrastructure will stagnate and rot. > The quality of the infrastructure of supporting tools is, in my > experience (and I ask you to trust for now the moment that I have > sufficient depth of experience in this area) one of the most significant > and least regarded aspects of C++ development. When it works well, it > fades into the background and everybody just takes it for granted. When > it obviously breaks, the average project team may send some unlucky > junior developer into the byzantine bowels of the build system to hack > away until things seemingly work again. Big mistake. > I might even go so far as to say that, > given the challenges involved in compiling and linking complex C++ > applications, the lack of a solid build infrastructure has been a > significant part of the perception that C++ is "too hard", Yes. Boost.Build was designed to address that. Version 2 is actually getting close. > right up there with raw pointers running wild and the absurd > expectation of actually managing memory allocation without a garbage > collector ; ) Coming back on topic, I believe the Boost community's > efforts in addressing the need for such an infrastructure is one of > the fundamental causes for the past, present, and future success of > Boost. Yep. > The tools need to provide a stable, reliable - perhaps > sometimes even boring - foundation: the base from which the library > projects can safely and sanely launch their expeditions. I agree. Unfortunately, the tools don't exist in the form we need today. Ergo Boost has to innovate in that area. ... > For example, justifying a change to Boost Build that > even trivially breaks most existing Jamfiles should require incredibly > strong arguments. That would be ideal, but unfortunately Boost.Build isn't that mature yet. We need to have some flexibility to improve things. -- Dave Abrahams Boost Consulting www.boost-consulting.com ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
