Build bugs in Python 2.2.1?

[Donn Cave]

Quoth martin at v.loewis.de (Martin v. Loewis):
| "Donn Cave" <donn at drizzle.com> writes:
|> I'm not the biggest fan of setup.py, but I don't think it needs
|> to be a choice between setup.py and autoconfig.  There are all
|> kinds of ways to get information from configure into setup.py,
|> and all we need is to find one that might be ideologically
|> acceptable to the folks who check stuff in.
|
| Reliance on autoconf can only work on systems where configure is run,
| which in turn require systems that have a /bin/sh. If setup.py needs
| to do things which it currently cannot do, distutils must be enhanced
| to allows these things to be done.

I'm not all that familiar with systems that don't have /bin/sh.
Are we talking about MacOS and Microsoft Windows?  The source
distribution README for 2.2.1 says "type ./configure".  I assume
folks on those platforms have some other arrangement for building
from source, but I'm sure it doesn't depend entirely on distutils -
you have to build Python before you can use distutils!  However
we get configuration information into setup.py from configure,
those platforms can take advantage of it too, to whatever extent
they need it.

Which probably won't amount to much.  I suspect the issues are
mostly relevant only to systems that have a /bin/sh - do they
have /usr/local and so forth?  Benefit to them of all this UNIX
specific stuff in distutils would be minimal.

1. You need autoconf, it can't be replaced by the thing it's
   trying to build.
2. autoconf is the de facto standard for build configuration,
   well known by the system admins who build things like Python.
3. autoconf is powerful, if not omnipotent, and while it presents
   the unpleasant appearance of a mountain of hacks, at least all
   those hacks are in one place and you don't have to spend all day
   trying to figure out where something's going wrong in the bowels
   of distutils.
4. All we need is an interface between autoconf and setup.py, some
   way to get those platform dependent paths and so forth from the
   run time configure rather than hard coding them in setup.py as
   is done at present.  If other platforms want in on it, that's
   probably going to work out fine.

	Donn Cave, donn at drizzle.com