This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: distutils and cross-compiling the extensions
Type: Stage: resolved
Components: Distutils Versions: Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: amyodov, eric.araujo, tarek
Priority: normal Keywords: patch

Created on 2011-10-24 23:41 by amyodov, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
distutils.patch amyodov, 2011-10-24 23:41
Messages (2)
msg146340 - (view) Author: Alexander Myodov (amyodov) Date: 2011-10-24 23:41
I was recently trying to cross-compile several extensions (host: Linux, target: Win32) using mingw-gcc, and noticed that there is quite a little amount of changes needed to distutils code to at least make proper win32-compabible modules.

Some of them require pretty noticeable functionality changes to distutils (like, adding a new option) thus they are unlikely a target for 2.7 anymore (though with some luck, any person who wants to follow my way and do cross-compilation, may just subclass the existing code). But some others are obvious bugs, and their fixes may still be useful for users stuck at 2.7.

1. (This is dubious but still is related to the problem, and was required to build some of the modules). "--include-dirs" and "--library-dirs" options to build_ext command support multiple paths separated by os.pathsep. For some reason (which I may be unaware of) "--libraries" option doesn't. A tiny fix just adds this support.

2. (more obvious issue) get_msvcr() function in distutils/cygwincompiler.py tries to guess the C runtime library which the target extension should link to. To do that, it tests the Python where the setup.py is *running* for what library it was linked to. But when the compilation target is Win32 but the compilation host is Linux, the hosts's Python won't contain such information. In this case, this function will return None. The result then gets assigned to self.dll_libraries (in an instance of CygwinCCompiler or Mingw32CCompiler), and gets used in a context which implies it is always an iterable (libraries.extend(self.dll_libraries)).

These changes, together with altering or subclassing Mingw32CCompiler to use a different compiler name (like, "i586-mingw32msvc-gcc" instead of "gcc"), make it possible to cross-compile a number of extensions which were non-compileable before.
msg146373 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-10-25 15:22
Hi Alexander,

Thanks for your interest in improving Python.  I’m forced to reject your request because

- Python 2.7 does not get new features (and support for cross-compilation would be one).

- distutils does not get new features (we had to freeze it because improvements broke many setup scripts depending on undocumented behavior or working around bugs).

- This request has been made many times already: http://mail.python.org/pipermail/python-dev/2011-March/110099.html

To get cross-compilation, here’s one would have to do:

- Work on distutils2, the replacement for distutils and setuptools (it’s included in Python 3.3 under the “packaging” name).

- Define exactly what is supported (cross-compiling from any platform to any platform for example), possibly by reviewing all other bug reports about and hashing things out on the distutils-sig mailing list.

- Think about getting buildbots running to make sure we don’t get regressions.
History
Date User Action Args
2022-04-11 14:57:23adminsetgithub: 57469
2011-10-25 15:22:38eric.araujosetstatus: open -> closed
messages: + msg146373

assignee: tarek -> eric.araujo
resolution: rejected
stage: resolved
2011-10-24 23:41:39amyodovcreate