Hello,
I've taken a new look at the future Grass Swig interface. I wrote a small Perl program which
- takes all C and H files from raster source tree and makes temporary copies of them under swig
- renames the main.c files and makes the "main" an ordinary function (renames function "main" and changes "exist"s to "return"s
- creates a Makefile.PL, from which it asks Perl to create a Makefile
- runs the Makefile, which produces an archive file of the object files (e.g. r_slope_aspect.a)
These archive files could now be used by the build process together with Swig generated wrapper codes to produce scripting language modules. I have not yet done this, but don't see big problems there, only a lot of small ones 
Although I'm using Perl's system above, I believe the resulting archive files can be used by other languages as well.
The current code in CVS can be used to create the fundamental Grass module and together with these command modules an usable set of Grass modules could be made (Grass library module, command modules for Raster and Vector).
There are issues I'd like to discuss with people interested in using Grass from Perl, Python or other scripting languages, like:
- current gisdefs.h is not completely Swig compatible, but could be used almost as such, should this be done?
- how to handle the fact that Grass commands print a lot of things to stderr?
- should the wrapper codes etc. be in the CVS? I do not think so.
- should the scripting language interface be OO in some way? (instead of simplistic and thin)
I don't yet have CVS access so I have not committed anything.
Ari