Re: initial stab at :import

Adriaan de Groot wrote:

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

When an action is invoked the scopes are setup to search for variables
in:
- the local scope of the action build commands.
- the call stack, scopes from where the action was invoked (with :do or
  :execute)
- the recipe where the action was defined (the module scope)
- the toplevel scope

This is the same as what is used for actions defined by the user, except
that the tree of parent recipes is not searched.  The difference with
":import" will be that it works as if the module is a child of the
toplevel recipe, thus it doesn't matter in which recipe the ":import"
command was executed first (it may appear several times, thus depending
on where it's used first would be confusing).

I think the code for implementing this is all there, can mostly be
copied from ":child".  The only thing that needs to be done is putting
the module directly under the top recipe, instead of below the current
recipe.

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

I think we need to make a difference between options that make the
":import java" work differently and options that make the actions behave
differently.  For the first an attribute would indeed be appropriate.
But it can't be used for the second one, because you would want to be
able to change the option _after_ importing the module.  For these using
the _top scope appears to be appropriate.

There is one alternative: give the scope of the module a name, so that
it can be accessed directly.  Perhaps we can use something like "m_java"
for the java module.  Thus the user could set $m_java.JAVAC to specify
the Java compiler to be used.  That sort-of fits with using "s_abc" for
user scopes and "_foo" for predefined scopes.

Main advantage of using m_java is that it's immediately clear what the
variable is for.  It also avoids name space pollution and conflicts
between two modules.  You can use $m_java.FLAGS then, instead of
$JAVAFLAGS.

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

This sounds like what is done with filetype plugins in Vim.  Most of
them are distributed with Vim, but the user has the choice to use his
own plugin instead.  Or use the standard plugin and then add something.

I don't think the choice between using the first module found or all of
them is to be done in the recipe that has the ":import" command.  The
modules on the system should specify if they can work together with
other modules.

More specifically, a module could contain a part that is done only once,
and a part that is an addition.  Most modules could look like this
(sketchy):

	if no-module-found-yet
	    :module-is-found-now
	    Define all the things for this module

The user may then add to other modules by ignoring that the module
was found alreaady.  E.g., to add an action or set a variable.

This is a bit complicated, because we would have to look for user
modules twice: first for whole modules, so that he can overrule the
standard module, and then a second time after loading the standard
module, so that he can add a few things.  Vim uses 'runtimepath' for
this.  It could be "$HOME/.vim,$VIMRUNTIME,$HOME/.vim/after".  You can
see $HOME/.vim is used twice, the "after" directory is for additions.

Although this is complicated, we might have to do this anyway to allow
the user to do exactly what he wants, without having to mess with the
installed Aap files (which will be overwritten when upgrading).

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

It's not only that this changes behavior, I think this is undesired.
Setting the default values is not the same thing as importing a module.
One might argue that the support for C and C++ in the default
recipe should be moved to a module.  For backwards compatibility we
could do an ":import c" then.  But somehow I don't see a problem in
making C a special case and supporting it without importing anything.
That is how make works as well.

-- 
OLD WOMAN: King of the WHO?
ARTHUR:    The Britons.
OLD WOMAN: Who are the Britons?
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///


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