Re: [scons-devel] auto-configuration plans

"David Snopek" <[email protected]>
Newsgroups gmane.comp.tools.aap.devel
Message-ID <[email protected]>
Bram Moolenaar said:
>> I think the abstraction is pretty obvious here.  Only the portion that
>> actually does the compiling, linking, and running is SCons specfic (or
>> should be ;-).  This consists mainly of the SConf class.  The actual
>> configure checks are simply Python functions that call the Try* members.
>> There are some extraneus SCons-isms in these functions for automatically
>> setting the environment which would also have to be abstracted but they
>> look minor at first glance.
>
> 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.

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

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

Thank you.
  -- David Snopek

Satellite Computing Solutions, LLC


-------------------------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.