Feedback from Boost Meeting

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-30 14:06:34

One fact was brought home to me at the Boost meeting in Curacao: I asked
the attendees for feedback about what we could be doing better at boost,
and (although it was hardly news to me) the clear answer I got was that
building and installing boost is too hard. I personally consider it an
embarrassment that it is taking so long to create a usable build system
in Boost.Build v2. I don't blame anyone but myself for this, but it is a
continuing problem for boost's users, developers, and testers. I have
been promising a revised build system for 6 months, and we have not
delivered. In order to be responsible to the three groups just
mentioned, we need a development plan with targets that we stand a
chance of meeting, and we need to make consistent, steady progress
towards our goals. We must do this, or fold up the project and leave
these people to find their own solutions.

That said, I believe in the design decisions we've made, and am
(extremely) excited about seeing them implemented. I am not sure exactly
what has been getting in our way recently, but I think one problem has
been that we haven't been carefully tending to the codebase. At least,
when I tried to delve into the code after losing my internet connection
on Friday I found myself confronted by what looks like unresolved
maintenance issues. Because we cannot always reach one another for
immediate clarification, it is important that what we leave behind in
the CVS can be picked up quickly and easily. Here are some example
problems I ran into:

* I don't understand what modules.localize is doing; it doesn't seem
well-thought-out to me. In particular, it only seems to be called one
way, with the export parameter set to "export", the 2nd optional
parameter set to "*", and the 3rd optional parameter empty. We have to
keep vague, untested stuff out of the codebase (functionality that isn't
used probably doesn't work). This might in part be my fault for not
making the module import/export mechanism sufficiently understandable,
but I think I clarified this in
http://groups.yahoo.com/group/jamboost/message/791 and it looks a bit as
though this clarification was never followed-up on.

* project-test1.jam still doesn't work. I'm not sure how I'd fix it,
since I can't be sure what it's supposed to be doing. It uses some
idioms which are alien to me. In particular, project.jam and
project-root.jam are using modules.localize (see above) and seem to be
trying to do something with modules (project-rules,
project-root-context) which should probably be done with base classes.
It seems clear to me that the user should have a clean module scope in
which to write Jamfile and project-root definitions, and that an
associated class instance should be used for all of the
build-system-specific definitions (print, etc.). The associations could
be stored, for example, in globals of the project-root module:

$($(project-root-path).target-object)

[or something]. I thought that was already decided, though:
http://groups.yahoo.com/group/jamboost/message/734

Again, this may not be a root cause of anything, but it's something I
can put my finger on. My sense of the situation is that we need to try
to react more quickly to feedback about the code we check in, so that
the CVS is always relatively healthy: tests should pass, code should be
easily understandible, there should be little or no duplication of
functionality, and no code implementing functionality which isn't used
somewhere in the system. The other issue I can see is that the
foundation of our system (project and Jamfile loading behavior) is still
broken, and it's pretty darned hard to make any progress on top of a
broken foundation. Hopefully, once we get that handled we'll be able to
move forward apace.

-Dave

P.S. If any of you see other obvious problems and/or solutions, please
bring them up so we can address them!

P.P.S. Vladimir, since we have this unit testing system with the
__test__ rules, do you think it would be possible to incorporate
the --debug flag in the Python-based test system? If you want
a --debug=quiet setting which doesn't yap about executing (or not
finding) the test rules, it's easy to arrange.

+---------------------------------------------------------------+
David Abrahams
C++ Booster (http://www.boost.org) O__ ==
Pythonista (http://www.python.org) c/ /'_ ==
resume: http://users.rcn.com/abrahams/resume.html (*) \(*) ==
email: david.abrahams_at_[hidden]
+---------------------------------------------------------------+