Re: [A-A-P-develop] initial stab at :import

[Bram M. <Br...@mo...>]

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 ..
> since using variables declared in the :imported recipe within the
> recipe causes scope errors later. I need to figure that out - possibly
> by keeping the pristine scope somewhere and looking up variables
> coming from actions in that scope within the scope.
> 
> Anyway, does this look vaguely like it's going in the right direction?

Thanks for making this.  It is certainly going in the right direction.

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.

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.

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.

Main question that remains is what stack of scopes is provided to the
imported module.  The minimum is the _top scope and the recipe scope of
the module itself.  How about the scopes that are used where the
":import" command is invoked?  I am not sure, but I would think that
this is irrelevant.  An ":import" should always work the same way, no
matter where it is invoked from.  This does mean that it's not possible
to something like this:

	JAVA_OPTION = off
	:import java		# won't be able to see JAVA_OPTION

That would have to be:

	_top.JAVA_OPTION = off
	:import java

Hint for the implementation: I think this means get_build_recdict()
should be used, passing only the recdict of the _top scope.  I'm not
sure about the details though.


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.

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.

-- 
TIM:    Too late.
ARTHUR: What?
TIM:    There he is!
   [They all turn,, and see a large white RABBIT lollop a few yards out of the
   cave.  Accompanied by terrifying chord and jarring metallic monster noise.]
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- Bram@Moolenaar.net -- 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  ///