Re: Re: [scons-devel] auto-configuration plans

Joerg Beyer wrote:

> David Snopek wrote:
> > Like I said many times before, the most we can hope to share is a battery
> > of configure tests.  These are just python functions that expect to have
> > access to a specific API given to them as a "context" object.  Under
> 
> that sounds possible. The tests "just" need to know, which tool to use
> (e.g. gcc or g++), which Libs to link to the try-compilation, which
> headers to include.
> 
> This context, as you call it, has to be updated by the checks.
> 
> if you take a look at my class FeatureTest, then you see
> right now, this are the member varibles:
> self.ConfDefFile = ConfDefs()
> self.features = {}
> self.Libs = []
> 
> one could put this in a thinner wrapper object - is that what David
> calls the context?
> 
> Bram, what do you think about this?

What we should try to do is put the knowledge of how configure tests are
done in a common module.  This is the tricky code that requires knowing
how compilers on all possible systems react to certain C code.  For
example, a simple test if a function is available requires the knowledge
that gcc may use stubs for a function.

If we can share this knowledge base and work on it together we will not
only avoid doing the same thing twice, the resulting implementation will
also work better and include the experience of more people.

For many tests the build system is invoked to build a C or C++ program.
Mostly that is simple, but there might be a few difficult cases.
Especially when testing arguments for the compiler or linker.  The main
thing here is to make sure the tests are done in exactly the same way as
the actual building will be done later.  How to pass the arguments from
the generic build module to the specific build tool (SCons or Aap) is
something I still need to figure out.

> > A-A-P, this context object would be connected to the A-A-P build system. 
> > If you insist on comming up with a "standalone" implementation that would
> > be a third, totally different thing.
> 
> I dont see, why a standalone system should be far away. Of course it has
> to parse the test configuration (which tests to run, what to expect),
> but that seems to be the largest outstanding thing for a standalone
> tool.
> 
>  From the useres point of view it would be _very_ nice to learn only
> one syntax to specify tests.

For simple tests something simple would certainly please users.  But
quite often you have to do some custom testing anyway.  The danger for
this standalone program is that it grows into a build system anyway.

Let's first make it work with Aap and SCons and see how well this works.
People who need to do configuration and know Python well will probably
like using SCons, others may like using an Aap recipe.

-- 
hundred-and-one symptoms of being an internet addict:
89. In addition to your e-mail address being on your business
    cards you even have your own domain.

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