Re: dllobject/libobject

On Wednesday 24 September 2003 22:53, Bram Moolenaar wrote:
> In the currently released versions the commands of an action do not
> search for $DC in the scope of the recipe where the action is defined.
> You must use $_recipe.DC to access the variable, this should work:
>
> 	DC = dcompiler
> 	:action compile object d
> 		:sys $_recipe.DC $source -o $target
>
> But that means a user can't overrule the variable value, assuming he
> doesn't know what recipe the action is defined in.

What I've been using in my libtool module (as posted) is:

	@dc = _no.get("DC")
	@if not dc:
		dc = $_recipe.DC

and then using $dc in the actual action. This makes overriding possible, and 
the DC setting itself local to the module.

> finally the recipe where the action was defined.  I have wondered if the
> recipe where the action is defined should be searched before the tree of
> recipes.  That might look more logical, but it's not backwards
> compatible.  Opinions?

Typically the module will define default values for all its variables, no? So 
then changing the order to defining recipe / recipe tree would effectively 
remove recipe tree from the search order. I'd leave it like it is.


> An alternative (this was mentioned before) is to give the language
> module a named scope.  That avoids name conflicts between different
> modules.  Then it should work like this:

Yes, that would be the most useful. I haven't figured out how to add a scope, 
though .. I thought it would either be automatic or follow from a 
create-topscope() call while initializing the recdicts in Scope.py, but I 
never managed to get my scope "_module" to be recognized.

Bram, can you give a hint?

-- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <[email protected]>
     Key fingerprint = 934E 31AA 80A7 723F 54F9  50ED 76AC EE01 FEA2 A3FE



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf