Re: initial stab at :import

On Wednesday 10 September 2003 12:13, you wrote:
> Adriaan de Groot wrote:
> > Find attached an initial attempt at implementing :import. I basically
> > copied the code from :include and :child. It doesn't _really_ work ..
>
> The issue with scopes...  The actions, routes and similar things that
> the module defines are global, thus that is not an issue.  We do want to
> allow the module to have its own variables, without worrying about
> conflicts with variables in other modules.  Thus creating a new scope
> for the module is appropriate.

Aye. You don't want them to be able to interfere with each other.



> When reading the module recipe it must be able to access variables in
> other scopes.  At least in the _top scope, possibly others.  For
> example, the module must be able to set _top.C_COMPILE_ACTION.  Thus
> only passing the newly created scope to read_recipe() is not sufficient.
> I suppose that's the problem you ran into.

No, not exactly. I'll explain below.

How about (ab)using attributes for the parameter passing _into_ the module, 
and letting it set stuff in _top? That makes it clear where the parameters to 
the module go.

> When executing build commands that the module provides the logic will
> kick in that sets up the scopes for the build commands, including the
> scope of the module recipe.  I don't think that something new needs to
> be done for this, it is similar to using :child.


I have this main.aap somewhere:

	:import d
	:program foo : bar.d

and this is the contents of my d.aap module (in the directory where the aap 
executable lives):

	:filetype
	        suffix d d
	MYVAR=cool
	:action compile object d
	        :print Compiling D ... $MYVAR
	:route d object
 	       compile


The problem is that MYVAR gets set in the scope of the module, but when the 
action is called (much later ...) the module's scope is nowhere to be found.

> That would have to be:
>
> 	_top.JAVA_OPTION = off
>
> 	:import java


:import {JAVA_OPTION=off} java

seems a lot cleaner to me, and not hard to implement.


> One nice addition that comes to mind: Suppose someone does ":import
> java", and no java module is present?  It wouldn't be too difficult to
> attempt downloading it.  Just like it's already done for packages, thus
> using the A-A-P web site to locate the module.  The user would be
> prompted if he wants Aap to dowload the "java" module for him.

Yes, that is a nice idea. It should be fairly straightforward, what with all 
the downloading examples already in the code. 



> A less ambitious idea is to search more than one directory for imports.
> There always is the problem that a distributed module may not do exactly
> what is desired, and the user wants to make a copy and improve it (to
> later submit it for inclusion in the distribution).  It is a good idea
> to keep the standard modules separately from self-made modules.

I'd suggest the following:

* :import should read from the exec-dir, and all the other standard dirs 
(default_dirs() should be extended to also return the executable's 
directory). It should be controllable whether _all_ files with the module's 
name from those dirs are to be read, or just the first one found. For 
instance, with {once}, if you want to abuse a "keyword" again. Nah, use {all} 
to indicate all copies, it seems like the rarer case.

ie. :import libtool reads the first libtool it finds, :import {all} libtool 
reads all of them it can find (starting with exedir, ending up in ~/.aap/). 

* on startup, :import {all} default.aap ... do NOT read any other .aap recipes 
in the default directories, since those are probably modules and should be 
read by :import.

The latter point changes AAP's behavior in a subtle way .. do you think enough 
people have extended .aap files installed there for it to be a big problem? 
It's solvable with a few :imports, in any case.


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