Der macOS-Build-Leitfaden für CPython

Der Platz des macOS-README in CPython

Das Repository python/cpython ist die CPython-Implementierung der Programmiersprache Python und wird in den Repository-Metadaten als "The Python programming language" beschrieben. Die Datei Mac/README.rst ist der macOS-spezifische Teil der Dokumentation. Sie behandelt, mit welchen Compilern die Kernentwickler testen, welche configure-Argumente Framework- und Universal-Binary-Builds steuern, welche Anwendungen mit einer Framework-Installation ausgeliefert werden, wie man eine Binärdistribution erstellt, wie man eine Framework-Installation deinstalliert und wie schwaches Linken (Weak Linking) ältere Bereitstellungsziele adressiert. Das Repository hat 74.165 Sterne und 35.137 Forks auf GitHub sowie 9.499 offene Issues, aber das README selbst diskutiert weder die Gesundheit des Projekts noch die Beitragsprozesse.

Compiler-Unterstützung auf macOS

Die Kernentwickler testen Builds auf macOS hauptsächlich mit Apples Compiler-Werkzeugen, entweder Xcode oder den Command Line Tools. Das README besagt, dass nur das Bauen mit einem Compiler unterstützt wird, der ein SDK enthält, das das Betriebssystem der Build-Maschine anvisiert, also die Xcode-Version, die mit dieser OS-Version ausgeliefert wurde, oder eine neuere. Für macOS 12 bedeutet das Xcode 13 und Xcode 14 (oder die entsprechenden Command Line Tools). Das Bauen mit anderen Compilern wie GCC funktioniert wahrscheinlich, wird aber nicht aktiv unterstützt. Das README legt nicht fest, welche Xcode-Versionen macOS-Versionen nach 12 entsprechen, und dokumentiert auch nicht, wie Builds mit Nicht-Apple-Toolchains verifiziert werden.

Universale Binaries und ihre Architekturvarianten

Ein Universal-Binary-Build von Python enthält Objektcode für mehr als eine CPU-Architektur, zusammengefasst in einer einzigen ausführbaren Datei oder Bibliothek, die auf jeder unterstützten Architektur mit nativer Geschwindigkeit läuft. Universale Dateien wurden in macOS 10.4 eingeführt, um Intel-Unterstützung zu den vorhandenen PowerPC-Maschinen hinzuzufügen. Die PPC-Unterstützung wurde in macOS 10.7 entfernt und die 32-Bit-Intel-Unterstützung in macOS 10.15, sodass aktuelles macOS nur noch eine Ausführungsarchitektur unterstützt, 64-Bit-Intel (x86_64), wobei arm64 über die Variante universal2 hinzukommt. Die configure-Option --enable-universalsdk aktiviert einen Universal-Build, und --with-universal-archs wählt die Variante: universal2 (arm64, x86_64), intel (i386, x86_64), intel-32 (i386), intel-64 (x86_64), 32-bit (ppc, i386), 3-way (i386, x86_64, ppc), 64-bit (ppc64, x86_64) oder all (ppc, ppc64, i386, x86_64). Das README enthält eine Tabelle, welche SDK- und Xcode-Kombinationen welche Varianten unterstützen, vom 10.4u-SDK mit Xcode 2, das nur 32-bit unterstützt, über SDKs ab 10.15, die nur intel-64 unterstützen, bis zu SDKs ab 11.0, die universal2 unterstützen.

Framework-Builds

Ein Framework-Build erstellt ein Python.framework statt einer traditionellen Unix-Installation. Der Hauptgrund, sich dafür zu entscheiden, ist die Erstellung von GUI-Programmen in Python: Mit Ausnahme von X11/XDarwin-basierten Toolkits müssen alle GUI-Programme aus einem macOS-Anwendungsbündel (.app) laufen, und ein Framework macht das möglich. Frameworks legen Python-bezogene Elemente außerdem nur an zwei Orten ab, /Library/Framework/Python.framework und /Applications/Python <VERSION>, was die Entfernung vereinfacht. Benutzer ohne Administratorrechte können eine Binärdistribution in ihrem Home-Verzeichnis installieren, ohne neu zu kompilieren. Die Build-Sequenz ist ./configure --enable-framework, make und make install. Bei der Installation an einem anderen Ort, etwa $HOME/Library/Frameworks, landen die Anwendungen in $HOME/Applications/Python-<VERSION> und die Befehlszeilenwerkzeuge in $HOME/bin. Das README merkt an, dass der Framework-Build auch die relevanten Teile des Mac-Teilbaums über das Ziel installmacsubtree installiert.

Die mitgelieferten Anwendungen

Eine Framework-Installation umfasst drei Arten von Programmen. IDLE.app ist eine integrierte Entwicklungsumgebung mit Editor und Debugger. Python Launcher.app behandelt Doppelklicks auf .py-, .pyc- und .pyw-Dateien: Bei den ersten beiden öffnet es ein Terminalfenster und führt das Skript mit dem normalen Befehlszeilen-Python aus; bei .pyw-Dateien führt es das Skript im Python.app-Interpreter aus, damit das Skript GUI-Arbeit verrichten kann. Wenn man die Option-Taste gedrückt hält, während man ein Skript zieht oder doppelklickt, kann man Laufzeitoptionen setzen; diese lassen sich auch dauerhaft über den Einstellungsdialog von Python Launcher festlegen. Das Programm pythonx.x führt Python-Skripte von der Befehlszeile aus. Früher wurden auch Kompatibilitätsaliase wie pythonwx.x installiert, aber ab 3.4.0 werden diese Aliase nicht mehr installiert. Das README dokumentiert nicht, was die versteckte Hilfsanwendung Python.app außer ihrer Funktion als Interpreter für .pyw-Skripte tut.

Erstellen einer Binärdistribution

Zum Erstellen einer Binärdistribution verweist das README auf das Skript Mac/BuildScript/build-installer.py. Das Skript lädt eine Reihe von Drittanbieter-Bibliotheken herunter und baut sie, konfiguriert und baut ein Framework-Python, installiert es, erstellt die Installer-Paketdateien und verpackt sie in ein DMG-Image. Es erstellt außerdem eine HTML-Kopie der Python-Dokumentation für diese Version, die in das Framework aufgenommen wird. Das Skript baut ein universales Binary, daher muss es unter macOS 10.4 oder neuer mit Xcode 2.1 oder neuer laufen, obwohl der Build-Prozess Abhängigkeiten hat, die unter macOS 10.4 nicht out of the box verfügbar sind. Das README rät, am sichersten auf einem System mit der minimal unterstützten macOS-Version zu bauen, und die resultierenden ausführbaren Dateien, gemeinsam genutzten Bibliotheken und .so-Bündel sorgfältig auf korrekte dynamische Link-Abhängigkeiten zu prüfen und zu testen. Der Build läuft vollständig isoliert in /tmp/_py, verwendet also nicht das normale Build-Verzeichnis und installiert nicht nach /. Das Skript muss aus dem BuildScript-Verzeichnis heraus ausgeführt werden und akzeptiert Befehlszeilenargumente, die mit --help dokumentiert sind.

Deinstallation und schwaches Linken

macOS bietet keinen zentralen Deinstaller für eine Framework-Installation. Die Entfernung erfolgt manuell: das Framework selbst in /Library/Frameworks/Python.framework, die Anwendungen in /Applications/Python X.Y und die symbolischen Links in /usr/local/bin, die alle auf Dateien im Versions/X.Y/bin-Verzeichnis des Frameworks zeigen. Wenn man eine Version aus einem Multi-Version-Framework entfernt, muss der Symlink Versions/Current angepasst werden, damit er auf eine installierte Version zeigt. Das README behandelt auch schwaches Linken: CPython kann mit dem neuesten SDK gebaut werden, während die Bereitstellung auf macOS 10.9 zielt, durch schwaches Linken von Symbolen, die in macOS 10.10 oder später eingeführt wurden. Dies erfordert Apples Compiler-Toolchain unter macOS 10.13 oder neuer. Die Implementierung verwendet ein HAVE_<FUNCTION>_RUNTIME-Makro, das der einzige Ausdruck in einer if-Anweisung sein muss. Das README behandelt weder Windows- noch Linux-Build-Anleitungen und diskutiert auch keine Leistung, Sicherheit oder die Python-Sprache selbst über die macOS-Build-Themen hinaus.

Redaktionelles Fazit

Die CPython beiliegende Lizenz ist die Python Software Foundation License Version 2. Sie gewährt eine nicht exklusive, lizenzgebührenfreie, weltweite Lizenz zur Nutzung, Vervielfältigung und Verbreitung von Python und verlangt, dass abgeleitete Werke eine Zusammenfassung der Änderungen enthalten. Die Lizenz stellt die Software auf einer AS-IS-Basis ohne Gewährleistungen bereit und sagt nichts über Sicherheit, Support oder Wartung aus.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository