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

Michael P. Reilly arcege@shore.net
Mon, 12 Jul 1999 14:56:21 -0400 (EDT)


[Charset iso-8859-1 unsupported, filtering to ASCII...]
> 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?
> 

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.

  -Arcege

-- 
------------------------------------------------------------------------
| Michael P. Reilly, Release Engineer | Email: arcege@shore.net        |
| Salem, Mass. USA  01970             |                                |
------------------------------------------------------------------------