Re: [scons-devel] auto-configuration plans

Christoph Wiedemann wrote:

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

Redirecting the output of a shell command indeed requires some
non-portable code.  It's a pity there is no standard Python way to do
this.  This is probably the most complicated part for executing the
configure tests.

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

The manual page doesn't say anything about TryBuild() and the like...
From reading the source code it's not clear what is part of the API and
what isn't.  Thus it's not clear what may change and what should not
change to remain backwards compatible.

Anyway, with the current approach I'll not have to worry about these
things.  It is unlikely that any SCons user will notice the split up of
SConf.py.

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

I'm still not sure what you are talking about.  You would not want to do
the configure phase every time you invoke the builder, of course.  Thus
the configure results are stored (in config.h etc.) and configure is
only run again when it's needed or when the user explicitly tells the
builder to.  This assumes the configuration phase is viewed as one
dependency of the configure output (config.h, etc.) on the configure
input (the configuration script).

Inside the configuration script there are hardly any things that are
repeated.  It is very unusual to do the same test twice.  Perhaps a few
things are duplicated when two high-level checks use the same low-level
check.  But caching these results will not give much speedup (and simply
using a variable for the result can also avoid doing a test twice).
There is also the overhead of caching itself to take into account.

If you don't want a separate configure phase and mix configure tests
with other building, then you indeed need to avoid that time consuming
tests are done again.  But I suppose this uses the standard SCons
dependency stuff, you would not need a separate caching mechanism on top
of the already existing one.

Hmm, perhaps the problem is that the SCons builders expect to store the
results of building in a file, and a configure check may only result in
a variable being set to "success" or "fail".  You could store that in a
file, but that's a lot of overhead.  Is this the reason to add a
separate caching mechanism for the configure checks?

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

Joerg Beyer posted his work on an Aap autoconf implementation yesterday.
So I'm all set to figure out what the common parts with SCons are and
how to interface them.

-- 
hundred-and-one symptoms of being an internet addict:
74. Your most erotic dreams are about cybersex

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