[Python-Dev] Using SCons for cross-compilation

David Boddie david at boddie.org.uk
Thu Nov 9 16:42:48 CET 2006

On Thu Nov 9 07:45:30 CET 2006, Anthony Baxter wrote:

> On Thursday 09 November 2006 16:30, Martin v. Löwis wrote:
> > Patch #841454 takes a stab at cross-compilation
> > (for MingW32 on a Linux system, in this case),
> > and proposes to use SCons instead of setup.py
> > to compile extension modules. Usage of SCons
> > would be restricted to cross-compilation (for
> > the moment).
> >
> > What do you think?
> So we'd now have 3 places to update when things change (setup.py, PCbuild 
> area, SCons)? How does this deal with the problems that autoconf has with 
> cross-compilation? It would seem to me that just fixing the extension module 
> building is a tiny part of the problem... or am I missing something?

I've been working on adding cross-compiling support to Python's build system,
too, though I've had the luxury of building on Linux for a target platform
that also runs Linux. Since the build system originally came from the GCC
project, it shouldn't surprise anyone that there's already a certain level
of support for cross-compilation built in. Simply setting the --build and
--host options is a good start, for example.

It seems that Martin's patch solves some problems I encountered more cleanly
(in certain respects) than the solutions I came up with. Here are some
issues I encountered (from memory):

 * The current system assumes that Parser/pgen will be built using the
   compiler being used for the rest of the build. This obviously isn't
   going to work when the executable is meant for the target platform.
   At the same time, the object files for pgen need to be compiled for
   the interpreter for the target platform.

 * The newly-compiled interpreter is used to compile the standard library,
   run tests and execute the setup.py file. Some of these things should
   be done by the interpreter, but it won't work on the host platform.
   On the other hand, the setup.py script should be run by the host's
   Python interpreter, but using information about the target interpreter's

 * There are various extensions defined in the setup.py file that are
   found and erroneously included if you execute it using the host's
   interpreter. Ideally, it would be possible to use the target's
   configuration to disable extensions, but a more configurable build
   process would also be welcome.

I'll try to look at Martin's patch at some point. I hope these observations
and suggestions help explain the current issues with the build system when


More information about the Python-Dev mailing list