While we're on the subject of distutils revision, here are a few things I've encountered about distutils which seem less than desirable. * There doesn't seem to be a way of supplying options on the command line for anything except the top-level command. Sometimes, e.g. I want to do an "install" but override some options for the "build_ext" that gets invoked by the install. But distutils won't let me, because those options are not recognised by the "install" command itself. If I try to get around this by doing a "build_ext" explicitly, then "install", the build_ext gets done again the second time around, without my options. I know I can do this using a config file, but the details of that don't seem to fit in my brain, and I have to go looking up the docs. Come to that, almost none of distutils seems to fit in my brain. Whenever I go to write a new setup.py I have to go and read the docs to remind myself what it's supposed to look like. * It seems to be next to impossible to override some of the options that get passed to the C compiler. For Pyrex I'd very much like to be able to turn off the -Wall that it seems to insist on using, but I haven't been able to find a way. Last time I tried, I got lost in a maze of twisty method calls, all alike. * The mechanisms for extending it seem clumsy. Since there's an Extension class, the you'd think the obvious way to add support for Pyrex would be to define a PyrexExtension type that embodied all the necessary knowledge to deal with a .pyx file. But that's not the way it seems to work. The current Pyrex distutils extension (which I didn't write) works by hijacking a pre-existing method designed for processing swig files. If that's really the cleanest way it can be done, something is badly wrong with the design. This is what I meant when I said I'd like a more Scons-like approach. Someone complained that Scons was too magical. I don't necessarily want it to behave exactly like Scons, but just to have the functionality divided into independent parts that can be composed in the manner of Scons, so that I could add a component for processing .pyx -> .c that builds on the existing components for dealing with .c files, and do it in an obvious and straight- forward way (and hopefully without having to be excessively Dutch in order to see the obviousness of it:-). -- Greg