On 5/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Sun May 13 2007, "Dean Michael Berris" <dmberris-AT-friendster.com> wrote:
I guess the thought of using something not-Boost maintained is brought about by the obvious hardships in maintaining .jam files in Boost.Build itself, and extending the tool chain as well as the mere maintenance of the code to fight fires and squash bugs that seem to be never ending.
Yup. Even with the new Getting Started Guide, just take a look at the number of complaints we've had on the user's list about being unable to build Boost 1.34. So far these are largely issues having to do with configuring the tools.
Someone (John Maddock I think) suggested we use something like a ./configure script which actually configured BBv2 for you -- i.e. edited your site-config.jam and/or user-config.jam file setting the correct/detected/configured toolkits. Might be worth looking at, and might even be interactive (Python anyone? ;) ). At any rate, I agree that there's a need to make the configuring Boost.Build easier -- and not require users to learn Jam before touching the configuration files.
Now I guess it might be too much to ask, but what if we allow some CMake specific stuff into Boost -- I mean, just include the build files in there and not require the Boost library to restructure itself and/or the files if it would be possible -- and let the users choose whether to use Boost.Jam+Boost.Build or CMake when building Boost for their system, we might be doing everyone a service by providing viable alternatives.
Not everyone; it would just worsen the problem we're trying to solve. It would create confusion and demand for everyone to support both systems.
I guess putting a disclaimer which says: "WARNING: using CMake is an option but is currently not *yet* the supported way of building Boost. If you encounter problems/issues with using CMake, please consider using Boost.Build to build Boost. If everything else fails, forward concerns to <insert users mailing list>." Might make sense, if the intention was to make CMake a viable option (and not replacement) for Boost.Build in the first few Boost releases. Much as some experienced developers in the field might disagree, "Users are not stupid." ;-)
I for one wouldn't want to see Boost.Build or Boost.Jam deprecated because I've greatly benefited from these technologies greatly. I just wish I could help make them tools better, or at least help it be the tool that the community would like it to be.
The support we've seen for keeping Boost.Build alive is obviously significant and merits consideration.
I guess now it's a matter of following up the support by converting "users" to "contributors". Lowering the barrier to entry might be a good first step, first by using more familiar (i.e. easier to use) tools for documentation, collaborative development (Trac+SVN of BBv2 anyone?), and a dedicated developer community (time based release system for BB?) working on Boost.Build alone might make more sense. That way, even if Boost does decide to use CMake, those still using Boost.Build in their organizations/projects will have a community to turn to when they need help. And people to throw their complaints / feature requests at. ;-) (Might be the wine+beer talking/typing... I'm not sure if I'll regret posting this "calling for arms to action" thing, but I do want to be part of this Boost.Build thing somehow. I'm particularly looking at building some support for a "Continuous Integration Environment" within Boost.Build which formatted outputs into nice HTML pages which might help in "remote building" and "regression testing") -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459