[Charset iso-8859-1 unsupported, filtering to ASCII...]
On Sat, 10 Jul 1999 11:09:53 +0200, "M.-A. Lemburg" email@example.com wrote:
Looks nice. Somethings that might be of use for the build process writer:
_ a way to test compiler features a la configure, e.g. a simple way to pass a small C program and evaluate the compiler error message (error or no error should suffice)
_ a way to test the availability of (shared) libs in much the same way, e.g. try to link an empty object file against a set of given libs to see if the linker finds the libs or not
_ a way to access the compiler/linker name and version
This sounds a lot like GNU autoconf so why we are not using it?
I agree that some things are still missing from autoconf, things like how to build shared libraries and dynamically loadable object files, but these could be defined for each system in a configuration file, perhaps written in Python. Look for example how libtool works, it's very simple to write a new makefile. Or take a look at the GNUstep's makefile package, is a combination of autoconf and makefiles, although it requires GNUmake (see http://www.gnustep.org).
The advantage of using autoconf is that we use something that already works very well with C code, so building C extensions is very simple. Plus developes are used to how autoconf/configure works. Not to mention we don't have to rewrite what configure does in Python, there are lots of ugly details we have to figure out in order for this to work really well.
In my view, I see autoconf plus some configuration files that define the flags used for building shared libraries (Python files, makefiles, shell scripts, doesn't matter) as being the right tools for building C extensions. For installing Python files, a simple Python tool that checks for package dependencies and installs the files in the appropriate places should be enough.
Am I missing something?
Please read the charter and requirements doc for the Distutils-SIG. You will find that the tools being discussed and developed are for the developers, not necessarily for the installers/end-users.
Autoconf is a tool for the developer, but does not test anything.. it generates a ./configure script, for UNIX-based systems only.
Autoconf requires m4 to be compiled and understood. M4 is very nice, but it is a language that not everyone can understand easily. Asking everyone to learn autoconf and m4 is as bad as the Perl crew requiring that Perl/C extensions be written in XS.
So the point of the Distutils SIG was to develop some standards and some (Python or C based) tools to aid the aspiring module developers out there in creating easily packagable distributions. Autoconf doesn't cut the mustard (tho I like it :), especially for non-UNIX developing.