Re: [scons-devel] auto-configuration plans

David Snopek wrote:

> > Making an interface to preform the building should not be difficult.
> > Although it might be required to remove a few SCons-isms.  This means
> > the Environment object is not available in the config module.  Only
> > environment variables, such as $CC, $CFLAGS, etc.  This probably has to
> > be separated anyway, so that the results of the config process are
> > separate from settings done in the SConsscript.
> 
> I am not sure exactly what you mean by the last sentance here.  Why would
> you want them to be seperate?  They need to be used for building later.

From the configure run you might get several variable values, such as
$CFLAGS and $LIBS.  But different parts of the build will want to use
different values.  For example building a C source file with the default
$CFLAGS instead of using the result from configure.

I'm sure there are various ways to access both the values from before
the configure checks and the values that configure detected.  The
configure run may use different variables for different config tests.
But you probably don't want to use both a $LIBS and a $CONFIG_LIBS
variable.  To me it sounds more logical to have a $LIBS in two scopes
(or two environments for SCons).

> > This has been discussed before.  The problem is that it would take a lot
> > of effort to make the SCons engine work with Aap.  Although the engine
> > has been designed to be used with other scripting languages, it is very
> > specific to how SCons works.  I have tried to use it for Aap but got
> > stuck.  I couldn't figure out how to make it work.
> >
> > I have challenged the SCons developers before to show how the SCons
> > engine could be used with Aap, but this has not produced results.
> > Apparently there is nobody willing to invest time in this.  By now it
> > will be very difficult anyway (e.g., Aap uses scopes for variables).
> 
> Essentially this means that the A-A-P code would interpret the recipes,
> but instead of using your custom build engine, it would use SCons calls. 
> For example:
> 
> :program myprog : main.c
> 			version.c
> 			work.c
> 			util.c
> 
> Would result in calls like:
> 
> env = Environment(CFLAGS = cur_aap_cflags, LIBFLAGS = cur_app_libflags, ...)
> env.Program(target = "myprog", source = aap_sources)

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.

> Anyway, I know it would be a big undertaking.  It just seems to me that
> both build tools would benefit greatly from sharing the underlying build
> system.  If you would be willing to try again, I would be willing to lend
> a hand (although my time is limited).

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.

-- 
I started out with nothing, and I still have most of it.
                                -- Michael Davis -- "Tonight Show"

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