[Distutils] Beginnings of a C/C++ compiler interface

Ovidiu Predescu ovidiu@cup.hp.com
Mon, 12 Jul 1999 10:40:26 -0700


On Sat, 10 Jul 1999 11:09:53 +0200, "M.-A. Lemburg" <mal@lemburg.com> wrote:

> [ccompiler.py]
> 
> 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?

Best regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/