Re: [Boost-build] Improving Boost Build?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-05-16 15:36:10

Hi Dave!

On 5/16/07, David Abrahams <dave_at_[hidden]> wrote:
>
> on Tue May 15 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
> >
> > 1) Consistent command line options (as Vladimir has already brought up): use
> > "feature=xyz" or "--feature=xyz" consistently throughout.  The first of
> > these looks to be the more commonly used within BBv2 at present, so I'd vote
> > for that, and keep "-" and "--" options for controlling how bjam itself
> > behaves (as in the -d and -a options).
>
> I think people will be confused anyway as posted elsewhere.  They
> don't know which identifiers are features and which are just options.
>

I think there are two parts of the problem here:

1) Users expect some things which (although might seem impossible to
provide) they expect to happen when doing "--feature",
"--feature=xyz", "feature=xyz" when invoking bjam. We can address this
somehow by providing *just one* definitive way of doing things with
bjam. We can't please everyone, but we've got to make a decision as to
how we intend bjam to be used not just when building Boost, but when
generally using the tool in other projects.

2) The documentation (*sigh* yet again) should reflect *only one
definitive way* of doing things. That means, saying something like

NOTE: "--toolset=" is no longer supported since Boost Release 1.XX's
packaged Boost.Jam binary. To build Boost using a particular toolset
at the command line, please do the following: bjam toolset=<your
toolset name here>"

might be necessary in succeeding documentation when we do decide to
choose one way of doing things as far as Boost.Jam's command line
parameters are concerned.

> > 2) Better docs.  Yes, I know it's been said before, but we really must get
> > the existing toolsets and their options documented.  This need not take too
> > long if someone would step up and volunteer to do it.
>
> ...and who would that be?  That's part of the problem.  Another
> problem is that the toolsets are totally inconsistent in how they
> work.
>

I think I don't have enough time, but if you need someone to
coordinate efforts and lay down a plan and actually do some doc monkey
work, you've got me lined up.

I *really* want to get involved in the documentation project, but as
I've already expressed, we'd get more help with the documentation if

  1) we made enough noise asking for help from the community
  2) lowered the barrier to entry in terms of collaborative document
writing (Wiki or Google Doc please) and
  3) actually had a time line and plan for the documentation project.

If no one doesn't want to volunteer to lead the effort a week after
BoostCon, consider me volunteering to do the planning and management
of the Boost.Build documentation project. Of course, I'd need all the
help I can get. ;-)

> > 5) More BBv2 developers :-) I actually think we do tools rather well
> > - both quickbook and BBv2 are so very nearly where they need to be,
> > but just need that final push that only more developers (and a wider
> > audience) can bring.  Part of the problem here is that Boost
> > attracts folks interested in C++ libraries, and who don't
> > necessarily want to spend their time hacking Jamfiles or whatever.
> > I'm not sure how solve this, unless maybe these tools can acquire a
> > life of their own outside of Boost as well as within it.
>
> Yeah, that's important.  But when even the people originally supposed
> to be co-developers on BBv2 have been worn out trying to understand
> the project's code, how are we going to get 3 or 4 more people to
> devote enough time to actually succeed where others have failed, and
> then make big contributions?
>

First answer I have to this question, is documentation. Let's please
either settle differences the manly way and call a spade a spade: we
have poor documentation, and thus let's fix it.

Second answer is lowering the barrier to entry in terms of
contribution. Ubuntu has a great open documentation project going on,
and they have very little structure and requirements when it comes to
helping write documentation. We might benefit from a time-based
release system just for the documentation -- which we can apply not
only to Boost.Build, but also to the Boost C++ documentation effort.

Yes, the pioneers have been burned out trying to make Boost.Build the
build system that it is today -- and I guess not getting enough
positive feedback contributes to the frustration. So the third answer
to this question is that rather than relying on the pioneers to do all
the work, I'd much rather be mentored by the pioneers (if time and
materials allow it) in terms of answering "how to do this?" questions
than actually burdening the original developers with the task of
actually making the changes. That way, people who actually want to
change things learn the ropes and then pick up from where the pioneers
left off.

This worked somehow in the Linux kernel development -- where Linus
Torvalds just holds a strategic vote towards which features go in, and
which features don't go in yet; he doesn't implement a lot of the cool
new things that go in, but rather he answers questions about how a
change in places would impact the overall system. Of course they
benefit from a large community of hackers and users, but that doesn't
mean to say we can't make the same model work in a smaller scale in
terms of Boost.Jam+Boost.Build development.

> That's the bottom line, IMO.  Who is going to step up and devote
> enough time to make something that can work as well as CMake?  In
> CMake it's one line to build a graphical binary installer.  We simply
> don't have enough time and resources to reach that level of
> sophistication.  Further, the CMake model has some advantages in that
> it is not trying to do configuration work every time you build.  Yes,
> we could do that in BBv2, too, but personally I just don't see the
> point in trying to outrun a project that actually has a bunch of
> knowledgeable developers and company funding behind it.
>

I guess shooting for the stars is not a bad idea, but I guess the
point of the discussion is now diverging on the actual use of CMake in
the Boost C++ Library and the improvement of Boost.Build. Trying to
make Boost.Build what CMake is might not be for the best interest of
Boost.Build users -- rather we should put in features that Boost.Build
users (such as myself, and others on the list) would like to have in
Boost.Build, and get more people involved in the effort.

So as far as the question of using CMake or not using CMake in the
Boost C++ Library is concerned, I'd leave that up to the Boost
developer community at large. However for the current discussion of
improving Boost.Build, I don't particularly see the need to turn
Boost.Build into a CMake look/work-alike if we intend to keep
Boost.Build a distinct and usable (better?) build system that it is.

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]