Hmmm, just as well I was away last week: I *think* I agree with almost all the points-of-view expressed concerning accessing autoconf-like features from distutils. I would have had a hard time participating in that discussion, agreeing with *everyone*. For my next trick, I'll try to figure out a position that's not inherently self-contradictory. ;-) But seriously; I think Marc-Andre's initial post had two points: * testing compiler/header/library features, existence, etc. (the bread and butter of autoconf, but only the beginning of what it is used for) * getting a more detailed platform description (compiler/linker name and version, and an OS/hardware description more detailed than os.name) The autoconf-ish stuff would be fun to do in Python, and a good test of how general my compiler framework is. It wouldn't be as hairy as autoconf itself, because all the horrible things about shell programming magically disappear. As Fred pointed out, it would also be more portable than the M4-generated shell script approach. But it would probably be trickier than I like to admit, and not necessary in most cases. Consider: many (most?) Python extensions are probably thin glue layers to larger C libraries. It is the large C libraries that have configure scripts to adapt themselves to a particular platform; given the existence of Python, a C compiler and library, and the big C library being wrapped, the Python glue extension should build trouble-free. I suspect a similar situation in Perl-land; I've just posted a question to perl-xs@perl.org to see if the experts over there agree with my assessment that autoconf-like features are occasionally handy, but not necessary for most extensions. (I further suspect that most Perl extension developers who need something autoconf-ish have rolled their own in Makefile.PL; if we do nothing autoconf-ish in the distutils, then I suspect that Python extension developers will do similarly in setup.py. It would be nice to have some basic "Does this header file exist?" "Does this library define that symbol?" type functionality, though.) Bottom line is, I suspect it's not essential for building basic Python extensions, and would be a layer on top of the platform-specific CCompiler subclasses... so it's not an immediate concern. Regarding Marc-Andre's other wish: yes, this is important! Sooner or later (probably sooner), somebody is going to want to say: if compiler == 'gcc' and platform == 'linux-x86': compier_options.append ('-funroll-loops') ...and that's probably only the beginning. The CCompiler framework only has a barebones notion of what's needed to compile and link Python extensions (and will know about binary executables, in order to build a new static Python). I'm not even sure of how to handle optimization/ debugging options in a portable way, much less something like -Wall or -funroll-loops (considering only one popular compiler). Ultimately some sort of "Oh, here, just add your own damn compiler options" cop-out will be needed, and the only way to make that workable is to allow the extension developer to make decisions based on the platform and compiler. Perhaps a distutils.platform module is called for, which could expose all these things in a standard way. How's this sound for a start: * OS class ('posix', 'windows') (aka os.name) * OS ('linux', 'solaris', 'irix', 'winnt') * OS version ('2.2.10', '2.7', '6.1', '4.0') * OS vendor ('redhat', 'suse', 'sun', 'sgi', 'microsoft') * architecture ('x86', 'sparc', 'mips', 'alpha', 'ppc') * processor ('586', '686', ... ???) * compiler ('gcc', 'mipspro', 'sunpro', 'msvc') * compiler version ('2.8.1', '7.5', '??', '5.0') (does Sun even have version numbers on their compiler?) OK, flame away. I'm sure someone will tell me that this is a good start, but not nearly detailed enough, and Greg Stein will tell me to stop being so obsessive about finicky little details. I'm inclined to the latter... anyone want to try their hand at hacking up such a module? Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913