christoph> Why don't you use the distutils module coming with python ?
christoph> They provide a platform-independent building/installing
christoph> mechanism of Python modules and c-extensions.
This is what my fellow Pythonistas suggest and is the workaround I'm
currently using. My reasons for not wanting to use distutils boils down
roughly to the fact that distutils does a poor job (I'm being kind)
emulating make. For example, if I have this chain of dependencies:
build/lib.linux-i686-2.3/array.so
depends on
build/temp.linux-i686-2.3/arraymodule.o
which depends on
Modules/arraymodule.c
(the locations of the .o and .so files are determined by distutils) and then
diddle some bits in arraymodule.c, neither .../arraymodule.o nor
.../array.so get rebuilt the next time I run make. For the person
installing one time from source this isn't a significant problem, but can be
a nightmare for a developer, especially if something more global changes
like Includes/object.h...
In short, while make is arcane, I trust it a lot more than distutils to get
build dependencies correct, and if automake reaches its goal, much of the
arcanity disappears.
Of secondary importance is the problem that if you use distutils you have to
maintain two sets of configuration files: the auto* stuff and a setup.py
file.
The workaround I mentioned above looks something like this:
build :
rm -rf build
python setup.py build
install : build
python setup.py install
No big deal at the moment because I am working on a small library which
contains a single extension module. The "rm -rf" trick would be impractical
for a large library though.
--
Skip Montanaro ([EMAIL PROTECTED] - http://www.mojam.com/)
