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

Well, we found out, that it is not just that easy to do this system- 
independent, if you want to create a config.log file. Maybe this is partly 
cause both of us, David and me, are no windows gurus ... However, we set up 
something that looks like it works (the piped_spawn functions in the 
corresponding Platform modules).

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

There *is* the current SCons API (documented in the SCons manpage). I just 
meant that this API shouldn't change.

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

Ok this sounds like it could work.

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

It is essential from the developer's point of view. Developers want things 
to go fast, so they won't accept a configuration tool which doesn't cache 
results at all. That's just my personal viewpoint.


After all, i think that it is worth trying to define an SCons-independant 
API for the tests. Both worlds would benefit from such an API and the tests 
defined on it.


Christoph


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