Re: [jamboost] Feedback from Boost Meeting

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 
all. 
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:
> http://groups.yahoo.com/group/jamboost/message/734

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

> 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