[Distutils] autoconf in distutils?

[lannert@uni-duesseldorf.de]

[I'm only subscribed to the digest; please bear with me if I'm out
 of sync with the current status of the discussion]

Greg Ward wrote:
> Sooner or
> later (probably sooner), somebody is going to want to say:
> 
>   if compiler == 'gcc' and platform == 'linux-x86':
>     compiler_options.append ('-funroll-loops')
>
> ...and that's probably only the beginning. ...

and, later on, suggested variables like OS class, OS name, OS version,
OS vendor, architecture, etc. etc.

IIRC, Marc-Andre's suggestion pointed into a somewhat different
direction: that the properties of a certain [instance of an] OS
would be described by a set of variables indicating system
"behaviour", rather than the formal vendor/version/architecture
description.

I would second this idea (and, IIDNRC, first it <wink>); maybe there
are some situations where I'd like to know if a certain system is a
SuSE or RedHat Linux, but usually I'd rather be interested in whether
it has SysV or Simple init (and where the init.d directory is), if
ps and friends want BSD or SysV style operands, if we have cc or gcc
or egcs, and the like.

The "intelligence" about the peculiarities of a vendor-x/version-y
installation should IMO not be built into a tool like distutils; it
would fail anyway for mangled or personalized systems (e.g. a SuSE
Linux updated with a few RH and some home-grown rpm's).

All the vendor-, installation- and configuration-specific data should
be specified as individual variables assignments, probably in several
files which are processed in a hierarchical order (like /etc/system.inst:
/var/lib/inst/*.inst:~/.inst/*.inst:.instrc, just to give a silly
example). They could be provided by (contributors to) distutils as a
first start, but ideally by the vendors or distribution builders
themselves <0.99 dream>.

I'd even go so far and suggest shell variable assignment format for
these files (name=value or name="value with blanks" etc.); it's far
from ideal, but since it could be used from non-pythonic tools there
would be an incentive for others to support and provide these files.

Python programs can, of course, parse these files, although it's not
trivial. I've written a ShellAssignment parser which understands "",
'', $var, ${var}, \ escapes, at least in the most common cases; I
wished there was a string.parsequotedstring() function ...

  Detlef