Einleitung

Es gibt einige verschiedene Ansätze, die zur Bewältigung dieses Problems eingesetzt werden, mit unterschiedlichem Aufwand für den Benutzer, aber alle erfordern einen erheblichen Aufwand. Dies liegt an der fehlenden standardisierten Cross-Kompilierungsinfrastruktur im Python-Paketierungsökosystem, das selbst aus der Komplexität von Cross-Builds resultiert und dies zu einer enormen Aufgabe macht.

Upstream-Unterstützung

Einige Hauptprojekte wie CPython, setuptools usw. bieten einige Unterstützung für die Cross-Kompilierung, aber dies ist inoffiziell und nach bestem Bemühen. Zum Beispiel ermöglicht das Modul sysconfig das Überschreiben des Datamodulnamens über die Umgebungsvariable _PYTHON_SYSCONFIGDATA_NAME, was für Cross-Builds erforderlich ist, und setuptools akzeptiert Patches [1], um seine Logik anzupassen/zu korrigieren, damit sie mit beliebten Workflows zum "Vortäuschen der Umgebung" kompatibel ist [2].

Das Fehlen von First-Party-Unterstützung in Upstream-Projekten führt dazu, dass die Cross-Kompilierung fragil ist und erheblichen Aufwand von den Benutzern erfordert. Gleichzeitig macht die mangelnde Standardisierung es für Upstreams schwieriger, die Unterstützung zu verbessern, da unklar ist, wie diese Funktion bereitgestellt werden soll.

Downstream-Ansätze

Die Ansätze zur Cross-Kompilierung liegen auf einem Spektrum, das von der Gestaltung her umfangreiche Benutzerinteraktion erfordert bis hin zu (idealerweise) fast keiner. Normalerweise basieren sie auf einer von zwei Hauptstrategien: die Verwendung einer Cross-Build-Umgebung oder das Vortäuschen der Zielumgebung.

Umgebungsabfrage

Wie oben erläutert, ist der größte Teil des Build-Systemcodes so geschrieben, dass er davon ausgeht, dass das Zielsystem dasselbe ist wie das, auf dem der Build stattfindet. Daher wird die Umgebungsabfrage normalerweise verwendet, um den Build zu steuern.

In diesem Abschnitt versuchen wir, die meisten Methoden zu dokumentieren, mit denen dies erreicht wird. Es sollte einen guten Überblick über die Umgebungsdetails geben, die von Build-Systemen benötigt werden.

>>> importlib.machinery.EXTENSION_SUFFIXES
[
   '.cpython-311-x86_64-linux-gnu.so',
   '.abi3.so',
   '.so',
]

>>> importlib.machinery.SOURCE_SUFFIXES
['.py']

>>> importlib.machinery.all_suffixes()
[
   '.py',
   '.pyc',
   '.cpython-311-x86_64-linux-gnu.so',
   '.abi3.so',
   '.so',
]

>>> sys.abiflags
''

>>> sys.api_version
1013

>>> sys.base_prefix
/usr

>>> sys.base_exec_prefix
/usr

>>> sys.byteorder
'little'

>>> sys.builtin_module_names
('_abc', '_ast', '_codecs', ...)

>>> sys.exec_prefix
/usr

>>> sys.executable
'/usr/bin/python'

>>> with open(sys.executable, 'rb') as f:
...   header = f.read(4)
...   if is_elf := (header == b'\x7fELF'):
...     elf_class = int(f.read(1))
...     size = {1: 52, 2: 64}.get(elf_class)
...     elf_header = f.read(size - 5)

>>> sys.float_info
sys.float_info(
   max=1.7976931348623157e+308,
   max_exp=1024,
   max_10_exp=308,
   min=2.2250738585072014e-308,
   min_exp=-1021,
   min_10_exp=-307,
   dig=15,
   mant_dig=53,
   epsilon=2.220446049250313e-16,
   radix=2,
   rounds=1,
)

>>> sys.getandroidapilevel()
21

>>> sys.getwindowsversion()
sys.getwindowsversion(
   major=10,
   minor=0,
   build=19045,
   platform=2,
   service_pack='',
)

>>> sys.hexversion
0x30b03f0

>>> sys.implementation
namespace(
   name='cpython',
   cache_tag='cpython-311',
   version=sys.version_info(
      major=3,
      minor=11,
      micro=3,
      releaselevel='final',
      serial=0,
   ),
   hexversion=0x30b03f0,
   _multiarch='x86_64-linux-gnu',
)

>>> sys.int_info
sys.int_info(
   bits_per_digit=30,
   sizeof_digit=4,
   default_max_str_digits=4300,
   str_digits_check_threshold=640,
)

>>> sys.maxsize
0x7fffffffffffffff

>>> sys.maxunicode
0x10ffff

>>> sys.platform
linux

>>> sys.prefix
/usr

>>> sys.platlibdir
lib

>>> sys.version_info
sys.version_info(
   major=3,
   minor=11,
   micro=3,
   releaselevel='final',
   serial=0,
)

>>> sys.thread_info
sys.thread_info(
   name='pthread',
   lock='semaphore',
   version='NPTL 2.37',
)

>>> sys.winver
3.8-32

>>> sysconfig.get_config_vars()
{ ... }
>>> sysconfig.get_config_var(...)
...

Relevante Informationen

Es gibt einige Informationen, die von Build-Systemen benötigt werden – z. B. plattformspezifische Besonderheiten –, die über viele Stellen verstreut sind, und es ist oft schwierig, Code mit Annahmen zu identifizieren, die darauf basieren. In diesem Abschnitt versuchen wir, die relevantesten Fälle zu dokumentieren.

crossenv

Beschreibung:

Virtuelle Umgebungen für die Cross-Kompilierung von Python-Erweiterungsmodulen.

URL:

https://github.com/benfogle/crossenv

crossenv ist ein Werkzeug zur Erstellung einer virtuellen Umgebung mit einer "monkeypatchten" Python-Installation, die in bestimmten Szenarien versucht, die Zielmaschine zu emulieren. Mehr zu diesem Ansatz finden Sie im Abschnitt Vortäuschen der Zielumgebung.

conda-forge

Beschreibung:

Eine Community-gesteuerte Sammlung von Rezepten, Build-Infrastrukturen und Distributionen für den conda-Paketmanager.

URL:

https://conda-forge.org/

XXX: Jaime wird eine kurze Zusammenfassung schreiben, sobald der PEP-Entwurf öffentlich ist.

XXX Verwendet einen modifizierten crossenv.

Yocto Project

Beschreibung:

Das Yocto Project ist ein Open-Source-Kollaborationsprojekt, das Entwicklern hilft, benutzerdefinierte Linux-basierte Systeme unabhängig von der Hardwarearchitektur zu erstellen.

URL:

https://www.yoctoproject.org/

XXX: E-Mail an die Mailingliste gesendet.

TODO

Buildroot

Beschreibung:

Buildroot ist ein einfaches, effizientes und einfach zu bedienendes Werkzeug zur Generierung von Embedded-Linux-Systemen durch Cross-Kompilierung.

URL:

https://buildroot.org/

TODO

Pyodide

Beschreibung:

Pyodide ist eine Python-Distribution für den Browser und Node.js, basierend auf WebAssembly.

URL:

https://pyodide.org/en/stable/

XXX: Hood sollte diesen Abschnitt überprüfen/erweitern.

Pyodide stellt eine Python-Distribution bereit, die mit dem Emscripten-Toolchain auf WebAssembly kompiliert wurde.

Es werden mehrere Aspekte der CPython-Installation und einiger externer Komponenten gepatcht. Ein benutzerdefinierter Paketmanager – micropip – der sowohl Pure- als auch wasm32/Emscripten-Wheels unterstützt, wird ebenfalls als Teil der Distribution bereitgestellt. Darüber hinaus wird ein Repository mit einer ausgewählten Reihe von Drittanbieterpaketen bereitgestellt und ist standardmäßig aktiviert.

Beeware

Beschreibung:

BeeWare ermöglicht es Ihnen, Ihre App in Python zu schreiben und sie auf mehreren Plattformen zu veröffentlichen.

URL:

https://beeware.org/

TODO

python-for-android

Beschreibung:

Verwandeln Sie Ihre Python-Anwendung in ein Android-APK.

URL:

https://github.com/kivy/python-for-android

Ressource https://github.com/Android-for-Python/Android-for-Python-Users

python-for-android ist ein Werkzeug zum Verpacken von Python-Apps unter Android. Es erstellt eine Python-Distribution mit Ihrer App und deren Abhängigkeiten.

Pure-Python-Abhängigkeiten werden automatisch und auf generische Weise behandelt, aber native Abhängigkeiten erfordern Rezepte. Eine Reihe von Rezepten für beliebte Abhängigkeiten wird bereitgestellt, aber Benutzer müssen ihre eigenen Rezepte für alle anderen nativen Abhängigkeiten bereitstellen.

kivy-ios

Beschreibung:

Toolchain zum Kompilieren von Python / Kivy / anderen Bibliotheken für iOS.

URL:

https://github.com/kivy/kivy-ios

kivy-ios ist ein Werkzeug zum Verpacken von Python-Apps unter iOS. Es stellt eine Toolchain zur Erstellung einer Python-Distribution mit Ihrer App und deren Abhängigkeiten bereit, sowie eine CLI zur Erstellung und Verwaltung von Xcode-Projekten, die mit der Toolchain integriert werden.

Es verwendet denselben Ansatz wie python-for-android (ebenfalls gepflegt vom Kivy-Projekt) für App-Abhängigkeiten – Pure-Python-Abhängigkeiten werden automatisch behandelt, aber native Abhängigkeiten erfordern Rezepte, und das Projekt stellt Rezepte für beliebte Abhängigkeiten bereit.

AidLearning

Beschreibung:

KI, Android, Linux, ARM: KI-Anwendungsentwicklungsplattform basierend auf der integrierten Ökologie von Android+Linux.

URL:

https://github.com/aidlearning/AidLearning-FrameWork

TODO

QPython

Beschreibung:

QPython ist die Python-Engine für Android.

URL:

https://github.com/qpython-android/qpython

TODO

pyqtdeploy

Beschreibung:

pyqtdeploy ist ein Werkzeug zur Bereitstellung von PyQt-Anwendungen.

URL:

https://www.riverbankcomputing.com/software/pyqtdeploy/

Kontakt https://www.riverbankcomputing.com/pipermail/pyqt/2023-May/thread.html Phil, den Maintainer kontaktiert

TODO

Chaquopy

Beschreibung:

Chaquopy bietet alles, was Sie benötigen, um Python-Komponenten in eine Android-App zu integrieren.

URL:

https://chaquo.com/chaquopy/

TODO

EDK II

Beschreibung:

EDK II ist eine moderne, funktionsreiche, plattformübergreifende Firmware-Entwicklungsumgebung für die UEFI- und PI-Spezifikationen.

URL:

https://github.com/tianocore/edk2-libc/tree/master/AppPkg/Applications/Python

TODO

ActivePython

Beschreibung:

Kommerzielle, qualitätsgesicherte Python-Distribution, die sich auf einfache Installation und plattformübergreifende Kompatibilität unter Windows, Linux, Mac OS X, Solaris, HP-UX und AIX konzentriert.

URL:

https://www.activestate.com/products/python/

TODO

Termux

Beschreibung:

Termux ist ein Android-Terminalemulator und eine Linux-Umgebungs-App, die direkt und ohne Rooting oder Setup funktioniert.

URL:

https://termux.dev/en/

TODO