Einleitung

Der Mechanismus Modules/Setup hat einige Mängel

• Leute müssen daran denken, Teile von Modules/Setup auszukommentieren, um alle möglichen Module zu erhalten.
• Das Verschieben von Setup in eine neue Version von Python ist mühsam; neue Module wurden hinzugefügt, so dass man nicht einfach die ältere Version kopieren kann, sondern die beiden Versionen abgleichen muss.
• Benutzer müssen herausfinden, wo die benötigten Bibliotheken, wie z.B. zlib, installiert sind.

Vorschlag

Verwenden Sie Distutils, um die mit Python gelieferten Module zu erstellen.

Die Änderungen können in mehrere Teile unterteilt werden

1. Distutils benötigt einige Python-Module, um Module erstellen zu können. Derzeit glaube ich, dass die minimale Liste posix, _sre und string ist.

   Diese Module müssen erstellt werden, bevor Distutils verwendet werden kann. Sie werden daher einfach fest in Modules/Makefile verdrahtet und automatisch erstellt.

2. Ein übergeordnetes setup.py-Skript wird geschrieben, das die auf dem System installierten Bibliotheken prüft und so viele Module wie möglich kompiliert.
3. Modules/Setup wird beibehalten und Einstellungen darin überschreiben das übliche Verhalten von setup.py, sodass Sie ein als fehlerhaft bekanntes Modul deaktivieren oder spezifische Kompilierungs- oder Linker-Flags angeben können. Im gängigen Fall, in dem setup.py korrekt funktioniert, bleibt jedoch alles in Setup auskommentiert. Die anderen Setup.* werden überflüssig, da nichts Setup automatisch generieren wird.

Der Patch wurde für Python 2.1 eingecheckt und anschließend modifiziert.

Implementierung

Patch #102588 auf SourceForge enthält den vorgeschlagenen Patch. Derzeit versucht der Patch, konservativ zu sein und so wenige Dateien wie möglich zu ändern, um das Zurückrollen des Patches zu vereinfachen. Zum Beispiel wird kein Versuch unternommen, die vorhandenen Build-Mechanismen zu entfernen. Solche Vereinfachungen können bis später im Beta-Zyklus warten, wenn wir sicher sind, dass der Patch beibehalten wird, oder sie können bis Python 2.2 warten.

Der Patch nimmt folgende Änderungen vor

• Nimmt einige notwendige Änderungen an distutils/sysconfig vor (diese werden separat eingecheckt)
• Im übergeordneten Makefile.in führt das Ziel "sharedmods" einfach "./python setup.py build" aus, und "sharedinstall" führt "./python setup.py install" aus. Das Ziel "clobber" löscht auch das Unterverzeichnis build/, in dem Distutils seine Ausgabe platziert.
• Modules/Setup.config.in enthält nur Einträge für die Module gc und thread; die Module readline, curses und db werden entfernt, da es nun die Aufgabe von setup.py ist, sie zu handhaben.
• Modules/Setup.dist enthält nun Einträge für nur 3 Module – _sre, posix und strop.
• Das configure-Skript erstellt setup.cfg aus setup.cfg.in. Dies ist aus zwei Gründen erforderlich: um das Kompilieren in Unterverzeichnissen zu ermöglichen und um das konfigurierte Installationspräfix zu erhalten.
• Fügt setup.py zum Stammverzeichnis des Quellbaums hinzu. setup.py ist das größte Stück des Puzzles, wenn auch nicht das komplizierteste. setup.py enthält eine Unterklasse der Klasse BuildExt und erweitert sie um eine Methode detect_modules(), die die Arbeit leistet, herauszufinden, wann Module kompiliert werden können, und sie zur Liste 'exts' hinzuzufügen.

Ungelöste Probleme

Müssen wir es ermöglichen, die 3 fest verdrahteten Module zu deaktivieren, ohne die Makefiles manuell zu bearbeiten? [Antwort: Nein.]

Distutils kompiliert Module immer als dynamische Bibliotheken. Wie unterstützen wir das Kompilieren als statische Bibliotheken in das resultierende Python-Binärprogramm?

[Antwort: Das Erstellen eines Python-Binärprogramms mit Distutils sollte machbar sein, obwohl es noch niemand implementiert hat. Dies sollte irgendwann geschehen, ist aber keine dringende Priorität, da das Herumspielen mit dem übergeordneten Makefile.pre.in ausreichend ist.]

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.