Re: [Boost-build] Future development

From: Benjamin Kosnik (bkoz_at_[hidden])
Date: 2007-10-03 16:43:56

> > If the Jam language is part of the problem (because it is so poorly
> > understood), does it make sense to still use Jamfiles as the
> > description language?

Ding ding ding.

> > Boost.Build has some really great ideas in it. The way features can
> > be defined and separately mapped onto the platform, how features
> > interact and propagate, the flexibility of generators... all of
> > these allow us to describe complex build systems rather easily.
> > These are good, solid ideas, and they work well in BBv2, so why
> > haven't we seen a more adoption of Boost.Build beyond boost?
> 
> "More" compared to what? I get the impression that Boost.Build is used
> outside Boost, and well, it was used outside boost even more Boost
> itself started moving to V2.

More adoption compared to cmake, gnu make, gnu autotools, ant, etc.

There is no doubt that Boost.Build is used outside of boost: witness
the postings on this list. 

Outside the boost community, however, the situation is unclear. 

One reference point is that boost build is not a required
dependency to build any package on fedora/redhat. Maybe other linux
distros have packages that use boost build.

If you attempt to qualify usage of build tools in general on linux (say
with debian popularity contest, link:)

http://popcon.debian.org/main/devel/by_recent

You'll see something like (rank/build tool)

2 	make (gnu)
53	ant
71	automake1.9
75 	automake
97	automake1.4
115	automake1.7
182	cmake
241	automake1.8
354 	bjam
368 	boost build

This is admittedly imprecise, but gives one an idea. 

Perhaps the situation is different on windows. I'll let someone else
try to come up with metrics for that platform.

> > I think the answer is "bjam". As you said above, the Jam language is
> > essentially undocumented. It's also a rather odd language, and its
> > eccentricities are exaggerated by the object-oriented system BBv2
> > has built on top of Jam. We picked Jam several years ago, when
> > Perforce was still working on it and it looked like there would be
> > an active community around Jam. That hasn't happened, and we're
> > somewhat isolated in our use of this language and build tool,
> > forced to customize and maintain "bjam" on our own.
> 
> You surely understand that with core in Python, the amount of
> maintenance and customization necessary for bjam will be greatly
> reduced, almost to the point of being zero.

Famous last words. 

FWIW, how is a rewrite into python addressing Doug's
meta comment about the Jam language itself? 

The BBv1 to BBv2 transition was long and painful. Now, with BBv3 a
total rewrite, I'd expect something similar in the future, and
boost-1.3x.0 to experience similar delays.

> > We can address many of the shortcomings of bjam, 
> > certainly, but we'll still be left maintaining our own, separate
> > build tool. If a new implementation of the language underlying
> > Boost.Build is in order, why not consider taking an existing build
> > system with a strong community as our starting point, implementing
> > the ideas of Boost.Build within that system? We get all of the
> > benefits of that community, including shared maintenance and
> > documentation tasks, a larger pool of contributors to draw from,
> > etc. The key, then, is to take the ideas of Boost.Build to that
> > community: they're great ideas, so I have no doubt that they'll
> > gain momentum in that community and we'll see far greater rewards
> > in the end.

Agreed 100%.

> Judging from the current distribution of user complains, it seems to
> me that Python port is going to be immediate improvement, and the end
> result will be pretty good. Other approaches seem much more risky.

Could you elaborate on what you see are the top 10 user complaints? I'm
curious.

-benjamin