Boost logo

Boost-Build :

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2005-01-24 06:26:09


thanks for your comments.

Em 21 Jan 2005, às 21:01, David Abrahams escreveu:

> Pedro Ferreira <pedro.ferreira_at_[hidden]> writes:
>> Dear all,
>> my apologies for taking _way_ longer than I expected to post this: for
>> a bunch of reasons I was unavailable for the last few weeks.
>> I attach a draft of a porting strategy (Overview.txt) and the code I
>> have already ported.
>> Comments are very much appreciated.
> Maybe I'm misinterpreting it, but based on statements like
> "PyBB needs not, and should not, have the concept of a Jamfile or
> similar. This would complicate its interface and add an additional
> burden for applications that do not use "project" files. "
> 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. 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.
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.

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

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;

- having to carry around a Manager 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, e.g. the ones in tools and tool/types: 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. 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!

Best regards,



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