[Distutils] Autoconf in Python
Tue, 20 Jun 2000 22:07:20 -0400
Those of you who follow python-checkins closely probably already know
this, but for the rest of you I think this will be news:
I now have a working demonstration of the long-mythical, frequently
procrastinated, "Autoconf-in-Python"! Marc-Andre, you were right -- it
wasn't too bad. I think I probably spent more time combing the Autoconf
docs for inspiration, and figuring out how to sensibly translate
Autoconf's byzantine shell/M4 interface into sensible OO Python, than I
did actually coding it.
Here's the bird's-eye view of how it works:
* module developer defines a custom command, "config_xxx", which
inherits from the standard "config" command (distutils.command.-
config.config). (I suggest we adopt the convention "config_" +
distribution_name -- which, come to think of it, is probably
a good convention for *all* extended commands defined in setup
* this custom "config" command then calls the various methods provided
by the standard "config" to probe the system. Currently available:
'try_cpp()', 'search_cpp()', 'try_compile()', 'try_link()',
'try_run()', 'check_header()', and 'check_func()'. (The 'try'
methods are fairly low-level and expect you to provide a chunk of
custom-crafted C/C++ code; the 'check' methods just take a header
name or function name or what-have-you, and Do The Right Thing.)
* the custom "config" command uses the result of the system probing to
determine preprocessor macros to define/undefine, include
directories to search, libraries to link against, library dirs to
search, and whatever else might be needed. Currently the standard
"config" command provides no support for this, although it probably
(My thinking is something like this: users can provide manual
overrides by editing the "[config]" section of the setup.cfg file;
the custom config command -- if any! -- will then either respect the
manual overrides or probe the system (or a combination, depending on
which manual overrides are present). At the end of the day, there
are a bunch of settings -- macros, include dirs, libraries, and
library dirs -- sitting in the "config" command object, which are
then used by the various "build" commands.
(This is not terribly general -- what if you want to build one
extension (or library or executable one way), but others
differently? -- but it's good enough. If you need to get fancy, go
right ahead: this is Python, the only barrier is your own
creativity. No fighting with shell quoting rules or M4 bizarritude.
A note on portability: yes, this is all heavily geared towards C and
C++. No matter what Sun says (lying all the way to the bank, no doubt),
I expect an Autoconf-ish facility will be necessary for grokking Java
installations to build JPython extensions -- but that ability is a long
ways off, definitely post-Distutils 1.0.
Also, I had to add a 'preprocess()' method to the CCompiler interface,
which is currently only implemented in UnixCCompiler. Thus, the
preprocessor-depending "config" methods ('try_cpp()', 'search_cpp()',
'check_header()') will die horribly on Windows and Mac OS. Please take
a look at the 'preprocess()' docstring and let me know if it can be
implemented portably, or if the interface will have to change.
Oh, Unix wizards: currently I just do "cc -E filename.c -o filename.i"
to run the preprocessor. Works with GCC, and ISTR that SGI's compiler
supports "-E" too. Anyone know how widely spread this convention is?
Should I implement some heuristics to figure out whether to use "cc -E"
or "/lib/cpp"? What other options are there?
I'm gonna check this in now. No time to make a snapshot tonight --
please get the latest CVS code and give this a whirl. The only test
case is mxDateTime (examples/mxdatetime_setup.py), and only
'check_func()' (and therefore 'try_link()') have been tested. Next up
is to add autoconfiguration to PIL's setup script.
Whee! this is fun... I guess I've written my code for the week, now back
to wading through all those patches...
Greg Ward - nerd firstname.lastname@example.org
Support bacteria -- it's the only culture some people have!