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?