Strong and weak points of distutils 1 Was: [Distutils] thoughts on distutils 1 & 2

[Lars Immisch]

Dear all,

I have not used distutils very much, but maybe in some slightly unusual 
situations. I'll briefly summarize what I believe are the strong and the 
weak points.

Strong points:

- support for binary installers. (I was compelled to use distutils in 
the first place because it is so easy to create Windows installers - 
which is a massive pain otherwise)

- basic C extensions multi platform compilation support is quite good. 
Sometimes library names must be adjusted across Windows/Unix, but that 
is often enough and much less painful than writing multiple makefiles 
(GNU make and nmake at least, not to mention the inter-Unix differences)

Weak points:

- build processes with more stages than compile and link need to extend 
distutils.
- insufficient SWIG support.

Both these weak points come from my experience with wrapping third party 
libraries into Python with SWIG. I typically generate the SWIG input 
files from the third-party headers and feed it into SWIG to get the C 
source, so I have preprocess, swig, compile and link as stages.

So:

- I'd like the C extension build system to be more loosely coupled from 
distutils or opened up, if only by more documentation (I don't know 
SCons first hand)

- I'd like to continue to get information from distutils how Python was 
compiled, linked and installed.

- Lars

 From Bob:

> Not all operating systems have a usable package management system 
> (Win32, Mac OS X, probably others).

What's wrong with Installer.app and/or PackageMaker? On Windows, there 
is MSI (but I will admit I have given up in disgust trying to create 
even a trivial installer "manually" with Orca.exe).