Cross-compilation support in distutils?
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
participants (1)
-
Tim Gilbert