Build bugs in Python 2.2.1?
jonathan at onegoodidea.com
Sun Aug 11 10:59:31 CEST 2002
On 10/8/2002 23:30, in article 1029018622.263483 at yasure, "Donn Cave"
<donn at drizzle.com> wrote:
> 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.
Much of the magic in setup.py is concerned with attempting to sort out the
UNIX-style architectures, all of which use autoconf for the initial stage of
the build process.
> 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.
I'm not worred at all about distutils. The problem for me is entirely with
setup.py. This uses a heap of guesswork to figure out how to build the
modules. Since autoconf is already doing a heap of guesswork to figure out
how to build the core, I don't see the point in having two mechanisms.
Especially when autoconf is far more capable at this and provides all the
necessary hooks to allow the process to be managed by external tools.
> 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.
This is the easiest part. The interface already exists. Generating a
Modules/Setup file is already done by configure for the thread and signal
modules. Extending this procedure to correctly configure the other modules
would be trivial.
I think it would make Python a lot more useful on UNIX-style platforms if it
could be built entirely from configure. Hand editing compile flags in
configuration files is something I hope to slowly eradicate from the face of
I don't see how any of this would impact the non-autoconf platforms, since
these already need special procedures to build. It would be fairly simple to
reduce setup.py to
if platform in ['mac','win32']:
# a hundred lines of special pleading
# slurp in the configure-generated settings from Modules/Setup.conf
More information about the Python-list