Re: [jamboost] Re: RFC: Proposal to port BBv2 to Python

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

David,

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,

Pedro