Re: [scons-devel] auto-configuration plans

David Snopek wrote:

> I understand now.  Under SCons you can just call env.Copy() before
> starting the configure.  I actually setup a seperate environment for each
> Program/Library/Object that needs its own configuration.

Right, SCons uses an environment to store these things.  In Aap it is
possible to use another scope.  I think both SCons and Aap use a
dictionary for that, this could be "lowest common denominator" that the
configure module uses.  Thus the intermediate configure results are
stored as key-value pairs in a dictionary, with the keys being variable
names like "LIBS" and "CPPFLAGS".


[about using the SCons engine in Aap]

> > It's not this simple.  Actions defined in the recipe for building and
> > compiling need to be used for ":program".  These include Aap commands,
> > thus can't be directly executed by the SCons engine.  The source files
> > may have attributes (e.g., to automatically download them when needed).
> > I think the SCons build engine would have to be expanded quite a bit to
> > support all the Aap features.
> 
> Ok, this is about to all be personal bias since I have never read through
> your code.  But I think it would be possible to provide all your
> functionality through hooks into your existing code.  If one of the files
> in the former example needed to be downloaded from somewhere you could do:
> 
> env.Command(target="foo.c", source="ftp://someftp.com/source/foo.c", \
>   action=AAP.DownloadFunction)
> 
> Imagine that AAP.DewnloadFunction is a python function that can take the
> given source string and environment to produce the file.  This would add
> the download information to the Node in the SCons dependancy tree.  You
> could have this call happen before or after the Program one.  The whole
> node tree is maintained in the background.

OK, but does this also take care of only downloading "foo.c" when it is
actually used?

This was actually just an example.  There are much more complicated
things.  I can't give an estimate if they could all be translated into
SCons engine calls or that there is a serious problem somehwere.  Making
that estimation is a substantial part of the work.


I just thought of another use of the configure module, if it is made to
work in a generic way: from distutils.


> > I don't have time to work in this, I'm afraid.  But if someone can show
> > us how the SCons build engine could be used in Aap and that it has
> > advantages, I will certainly consider making Aap work that way.
> 
> The advantages would be that we wouldn't be duplicating our efforts.  That
> is probably about it.

Only the duplication for the engine part.  For Aap that is actually only
a very small part of the code (perhaps 5%).  Translating the
functionality into SCons engine calls might end up being more than that.
I don't don't know really.  Again, making an estimate for this would
already be lots of work, which I currently don't have time for.

Sharing the build engine is actually not that interesting, since it is
already implemented and quite stable (both for SCons and Aap).  Trying
to share something that is still very much in development, such as the
configure module, sounds much more interesting.

-- 
Light travels faster than sound.  This is why some people 
appear bright until you hear them speak

 /// 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 sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01