[Distutils] autoconf in distutils?

[gward@cnri.reston.va.us]

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