Re: [boost] Boost building with CMake

From: Dean Michael Berris (dmberris_at_[hidden])
Date: 2007-05-16 14:46:16

On 5/16/07, David Abrahams <dave_at_[hidden]> 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
[phone]