Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-03 05:45:44

David Abrahams wrote:
> 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.

This is pretty strong statement, but since nobody is really going to "fold
up" anything I won't comment on it.

I don't think that development plan is the problem, at least m1 is quite
clear for me. I think the problem is that we develop too slow. I don't know
why, precisely. But maybe:
1. We should all be fluent with all the codebase. I'm not sure that all of us
understand all the code. At least the core modules must be well-understood by
2. We should have todo list with well understood items and preferrable,
somebody should be assigned to each item.

> 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.

Yes. Actually, I always try to run tests before comitting and look throught
"cvs diff" output. Would it be reasonable that anybody finding
obscure/untested code just post a notice about that?

> 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:

This was discussed, but never decided. We can change it later, when we
implement associating project targets with project modules and declaring main

> 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.

Yes. Do you suggest reviwing other's commits. That could be a good idea, but
we'd need some automatic notification. (cvs watch happenned to be just
terrible in practice, maybe commit emails will turn out to be better).

> 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.

I hope... but since project.jam appears to work now we can just see.

> 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.

As I see, you've made the changes already.

- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at