Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2005-01-24 17:05:49

Pedro Ferreira <pedro.ferreira_at_[hidden]> writes:

>> this looks like a complete rearchitecture of Boost.Build, which casts
>> aside much valuable design work.
> No, that was not my intent. What I meant here is that the concept of
> having projects stored in files needs not be embedded in the core.

Oh, that's fine then.

> I didn't mean to dismiss the concept of a project at all. My idea
> was to delegate that to the parser - e.g. bjam parser - which could
> be signalled by the core that the project at a certain location
> needs to be loaded.

I'm sorry; what, specifically, would be delegated to the parser?

> Still, at least at the initial phase of porting, I have no strong
> feelings against this.
>> That makes me very worried and much less inclined to support the
>> effort.
> Please bear in mind that I sent a request for comments. I just
> collected a bunch of ideas into what I thought was a reasonable
> strawman proposal for this work. I didn't mean it to be definitive, nor
> do I want do all this by myself: I just want (need) this to be working
> as soon as possible, so I am willing to collaborate with and support
> the effort of anyone who has better or more appropriate ideas.

That's good.

>> I don't think it's neccessary to prohibit global variables for things
>> like type registrations. There are many reasons it's reasonable to
>> assume that type registration needn't interfere with concurrent
>> launching of build tasks. That just seems like it could be a huge
>> complication for little or no gain.
> I agree that global variables are not, in general, a problem for types
> and similar things. They even have some advantages, e.g. for
> registering types automatically, like it is done in BBv2, just by
> importing a file.
> Still, I have strong feelings against globals in general - I'm sure
> we've all been bitten by them more often than not - and that's why I
> proposed it as I did.

It's been a long time since I've been so bitten, but then I tend to
avoid globals ;-)

> Plus, it simplifies testing, as you don't need to clear global
> variables to see if things are working and, if it turns out that it is
> indeed necessary to make these non-global, it will be way more
> difficult to do it afterwards.

That's a good point.

> As for the complications you suggest, I see them in three aspects:
> - in the porting itself: creating a class for holding the per module
> globals basically boils down to add a class declaration and indent all
> the code. This pushes all variables and methods into that class;

This sounds like it might be insufficiently abstracted. A class
usually shouldn't just be a pile of variables, and...

> - having to carry around a Manager

...right there, the fact that you're calling this thing a "manager" is
possibly a good indication of that insufficient abstraction.

> object (which contains an instance of the TypeRegistry): this is
> sometimes a pain. Still, the manager is needed for most anything I
> think we agree cannot be global, so it will be needed anyway;
> - stand alone modules that declare targets and features need access to
> the current Manager

Once there's a "current" Manager you have globals again.

> , e.g. the ones in tools and tool/types:

Those modules are "stand alone?" In what sense?

> we can move
> the code in those modules into a function with a well-known name, say
> 'register', which receives a Manager instance as a parameter.

I can't picture what you're describing.

> The core could load the module, check if there is such a function,
> and call it with the appropriate Manager instance.
> Looking forward to your comments!

I'm very confused, but less worried than I was.

Dave Abrahams
Boost Consulting

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