Boost logo

Boost-Build :

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2005-01-25 10:59:20

David Abrahams wrote:

>>>>>, e.g. the ones in tools and tool/types:
>>>>Those modules are "stand alone?" In what sense?
>>Bad wording. I meant that, when they are loaded, global variables are
>>'automagically' set.
>I still don't understand. Plus, I've lost the context. Can you
>rephrase the whole statement and explain?

In BBv2, modules that declare targets and features (e.g. the ones in tools and tool/types) need no context to do their job, for they operate on global variables.
In PyBB, not having global variables, they need access to a Manager object. That is why I proposed what is below.

>>>>>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.
>>Consider tools/types/cpp.jam. With BBv2, when you import this module
>>the type 'CPP' is added to the global list of types.
>>Without global variables, you need to pass a context to the cpp.jam
>>counterpart in PyBB.
>>My proposal is to implement a function along the lines of:
>>def importXXX (manager, module_name):
>> import_the_module (module_name)
>> if has_register_function (module_name):
>> call_register_function (manager, module_name)
>Hm. This doesn't make too much sense to me. After all, modules can
>only be loaded once. Once they are loaded, their "globals" (really
>module-local variables) have to be set.

What about:

def importXXX (manager, module_name):

if not imported (module_name):
import_the_module (module_name)

if has_register_function (module_name):
call_register_function (manager, module_name)

> I'm feeling doubtful again
>about the wisdom of subverting this model, especially because it fits
>so well into Python's model for bindings in a module.

I'm with when you mention ease of use. By all means, it's easier to use
globals. Then again, I think it's cleaner not to and am very worried
that if we go down that path we'll regret it.
More advice please.

>>Then Tools/Types/ would be:
>Please, can we have all_lowercase module names?!
Sure, but that definitely is religious :-)
What about class names and file names?

>>def register (manager):
>> manager.types ().type ('CPP', ['cpp', 'cxx', 'cc'])
>Looks icky to me.

Sure it sould be simpler to do

types.type ('CPP', ['cpp', 'cxx', 'cc'])

but I'm ready to trade neatness for security.
Still, I agree with you that globals for types, features and similar are
not showstoppers (bar the testability) but I feel uncomfortable about
that. What do you think?

>BTW, I know this is probably a religious issue, but space separating
>function names from argument lists makes them hard to read because you
>can't visually "grep for [a-z](" to find all calls.
It is religious but I don't have a problem with that. I'll try.
BTW, what's the general feeling about that?



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