python-peps/pep-0229.txt

122 lines
4.2 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

PEP: 229
Title: Using Distutils to Build Python
Version: $Revision$
Author: akuchlin@mems-exchange.org (A.M. Kuchling)
Status: Draft
Type: Standards
Created: 16-Nov-2000
Post-History:
Introduction
The Modules/Setup mechanism has some flaws:
* People have to remember to uncomment bits of Modules/Setup in
order to get all the possible modules.
* Moving Setup to a new version of Python is tedious; new modules
have been added, so you can't just copy the older version, but
have to reconcile the two versions.
* Users have to figure out where the needed libraries, such as
zlib, are installed.
Proposal
Use the Distutils to build the modules that come with Python.
The changes can be broken up into several pieces:
1. The Distutils needs some Python modules to be able to build
modules. Currently I believe the minimal list is posix, _sre,
and string.
These modules will have to be built before the Distutils can be
used, so they'll simply be hardwired into Modules/Makefile and
be automatically built.
2. A top-level setup.py script will be written that checks the
libraries installed on the system and compiles as many modules
as possible.
3. Modules/Setup will be kept and settings in it will override
setup.py's usual behavior, so you can disable a module known
to be buggy, or specify particular compilation or linker flags.
However, in the common case where setup.py works correctly,
everything in Setup will remain commented out. The other
Setup.* become unnecessary, since nothing will be generating
Setup automatically.
Implementation
Patch #102588 on SourceForge contains the proposed patch.
Currently the patch tries to be conservative and to change as few
files as possible, in order to simplify backing out the patch.
For example, no attempt is made to rip out the existing build
mechanisms. Such simplifications can wait for later in the beta
cycle, when we're certain the patch will be left in, or they can
wait for Python 2.2.
The patch makes the following changes:
* Makes some required changes to distutils/sysconfig (these will
be checked in separately)
* In the top-level Makefile.in, the "sharedmods" target simply
runs "./python setup.py build", and "sharedinstall" runs
"./python setup.py install". The "clobber" target also deletes
the build/ subdirectory where Distutils puts its output.
* Modules/Setup.config.in only contains entries for the gc and thread
modules; the readline, curses, and db modules are removed because
it's now setup.py's job to handle them.
* Modules/Setup.dist now contains entries for only 3 modules --
_sre, posix, and strop.
* The configure script builds setup.cfg from setup.cfg.in. This
is needed for two reasons: to make building in subdirectories
work, and to get the configured installation prefix.
* Adds setup.py to the top directory of the source tree. setup.py
is the largest piece of the puzzle, though not the most
complicated. setup.py contains a subclass of the BuildExt
class, and extends it with a detect_modules() method that does
the work of figuring out when modules can be compiled, and adding
them to the 'exts' list.
Unresolved Issues
Do we need to make it possible to disable the 3 hard-wired modules
without manually hacking the Makefiles? If yes, perhaps a
configure switch is sufficient.
The Distutils always compile modules as shared libraries. How do
we support compiling them statically into the resulting Python
binary?
[Answer: building a Python binary with the Distutils should be
feasible, though no one has implemented it yet. This should be
done, though the main setup.py will probably need to implement
its own BuildExt subclass anyway.]
makesetup and the other contents of $(LIBPL)/config need to be
preserved for compatibility with existing modules; for how many
versions do we need to keep them around?
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: