[Distutils] Cross-compilation support in distutils?

[Tim Gilbert]

Hello dist-utiliarians,

[Sorry for the long message.]

I've recently been trying to port Python to the OpenWRT platform (see 
http://openwrt.ksilebo.net) - it's a mipsel-based wireless router 
running Linux with about 2MB of flash memory and 2MB of RAM.

While this machine excels at performing its raison d'etre of routing 
packets from hither to yon, one thing it probably won't excel at is 
compiling Python from source (or indeed, being able to store a python 
build in memory, but that's another story).  Therefore I've been trying 
to cross-compile python from my notebook (running gentoo linux on amd64, 
FWIW) to mipsel.

As anybody who might have tried to cross-compile python before has 
probably noticed, this isn't easy.  Although more recent versions of the 
python autoconf script don't compile code to determine what capabilities 
gcc has (these tests will fail because the generated output files are 
for the mipsel architecture rather than amd64), the setup.py script does 
perform tests to determine what libraries can be loaded, and these tests 
assume that the host architecture is the same as the target architecture 
(and likewise that the host environment - installed libraries, etc. - is 
the same as the target environment).

Another cross-compilation problem with the build process is that it 
builds a version of python to run setup.py, and obviously this version 
will be compiled for the target architecture.  I've solved this problem 
by copying somebody else's idea and doing this sequence of events:

     ./configure
     make ./python ./Parser/pgen
     mv ./python ./hostpython
     mv ./Parser/pgen ./Parser/hostpgen
     make distclean

...and then modifying Makefile.pre.in to use ./hostpython rather than 
python for running setup.py.

After much furrowing of my brow and hacking of the makefile I've managed 
to get the compilation to go through the whole way, but distutils thinks 
that none of the modules are available, so it renames them all to 
spam_failed.so.

In fact, for the python distribution I'd like to install, most of those 
modules will not be there.  I'm still playing around with a script to 
choose the ones I'd like and include them.

Once I'm a little farther along I'll put up a web page with some patches 
and things that will hopefully make this all a little clearer, but for 
now I'd like to get a little input.

1. Is there interest in adding cross-compilation support to distutils? 
(Beyond that of yours truly.)  If so, I'd like to get a discussion going 
on some options for how to do this - especially, I'd like to have a way 
to specify via configure arguments or a python script which libraries to 
include.

2. (This is probably more general than just a distutils issue.)  Is 
there interest in making a "no-batteries-included" version of python, 
especially one for embedded systems such as the OpenWRT?  I haven't yet 
explored this much, but I would like to be able to strip out features 
which I don't need from the standard python distribution (ie, complex 
numbers, tk, audio perhaps even threading if ucLibc doesn't support it). 
  It would be nice if this was supported out of the box in python's 
build process, although I can see all kinds of good reasons why it's a 
bad idea.

I will be glad to be of assistance in either of these two efforts, and 
I'd very much appreciate pointers and advice on how to go about either 
one of these tasks, even if they are not deemed fit for the official 
distribution.

Finally, here are a few links that may be of interest.

Cross-compiling python for ARM howto:
     http://www.ailis.de/~k/docs/crosscompiling/python.php

Reduced Python from the Pippy project:
 
http://sourceforge.net/project/showfiles.php?group_id=47300&package_id=77864

Thanks very much...
Tim