Re: [scons-devel] auto-configuration plans

Christoph Wiedemann wrote:

> Of course i can understand your point, but if you'd like to build a 
> complete, standalone replacement of autoconf including custom tests,
> you'll probably end up with re-implementing much of the code we
> already have in scons (or somehing similar).

The basic thing of auto-configuration is running a compiler and find out
if it fails or not.  This only requires being able to run the compiler.
That doesn't require re-implementing parts of SCons, os.system() does
most of the work.  That is the simple part, we probably don't need to
discuss this.  The more complicated part is what needs to be discussed.

> 1. SCons went beta recently, so we should try hard to fix the API including 
> the API to the SConf subsystem. The affected API is the Configure - call, 
> but also the Custom-Test stuff.

Currently there is no API.  At least, I could not find it.  Since the
use of the SConf module is quite SCons-specific I already suggested to
make an interface at a lower level.  That avoids modifying parts of
SCons that use the SConf module.  And makes it easier to define an
interface that is not SCons-specific.

> 2. It's relatively easy to implement TryCompile, TryLink and TryRun "build- 
> system-independent", but it's absolutely non-obvious, how to implement 
> TryAction and how to manage the environment changes. I believe that the 
> first feature is very useful for writing custom checks, and the second 
> feature is essential. You should remember, that a SCons environment is more 
> than a dict mapping strings to strings (we also have variables mapping to 
> python functions ...)

I don't see how TryAction can be done independent of SCons, since it
depends on the concept of a builder.  I don't think this can be moved to
the generic part, thus it will have to remain in SConf.py.

The environment changes are generic for as far as they involve setting
variable values.  Autoconf doesn't do much more than setting shell
variables, thus I don't think the generic Python configure module would
need more.

Changing SCons specific things in an SCons environment object is not
generic, of course.  How the generic environment can be separated from
an SCons environment object and merged back is to be investigated.  It
might be possible to simply pass the SCons environment object to the
generic part, so long as it behaves like a Python dictionary and the
generic part doesn't touch any SCons-specific parts.

> 3. Caching the checks is really essential for a usable autoconf 
> replacement. I doubt, that a completely non-caching autoconf version would 
> be accepted by users. Though not perfect yet, the current caching mechanism 
> of scons is rather good, and i wouldn't like to see this good thing 
> dying...

I don't see why caching is essential.  Can you explain?

-- 
"I simultaneously try to keep my head in the clouds and my feet on the
ground.  Sometimes it's a stretch, though."              -- Larry Wall

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