3. Python konfigurieren¶
3.1. Build-Voraussetzungen¶
Merkmale und Mindestversionen, die zum Erstellen von CPython erforderlich sind
Ein C11-Compiler. Optionale C11-Funktionen sind nicht erforderlich.
Unter Windows ist Microsoft Visual Studio 2017 oder neuer erforderlich.
Unterstützung für IEEE 754 Gleitkommazahlen und Floating-Point Not-a-Number (NaN).
Unterstützung für Threads.
Zum Erstellen optionaler Module
libffi 3.3.0 ist die empfohlene Mindestversion für das Modul
ctypes.liblzma, für das Modullzma.libncursesoderlibncursesw, für das Modulcurses.libpaneloderlibpanelw, für das Modulcurses.panel.libreadline oder libedit für das Modul
readline.OpenSSL 1.1.1 ist die Mindestversion und OpenSSL 3.0.18 ist die empfohlene Mindestversion für die Erweiterungsmodule
sslundhashlib.zlib 1.1.4 ist die empfohlene Mindestversion für das Modul
zlib.zstd 1.4.5 ist die Mindestversion für das Modul
compression.zstd.
Eine vollständige Liste der Abhängigkeiten, die zum Erstellen aller Module erforderlich sind, und wie Sie diese installieren, finden Sie im Devguide.
Autoconf 2.72 und aclocal 1.16.5 sind erforderlich, um das
configure-Skript neu zu generieren.
Geändert in Version 3.1: Tcl/Tk Version 8.3.1 ist nun erforderlich.
Geändert in Version 3.5: Unter Windows ist Visual Studio 2015 oder neuer erforderlich. Tcl/Tk Version 8.4 ist nun erforderlich.
Geändert in Version 3.6: Ausgewählte C99-Funktionen sind nun erforderlich, wie <stdint.h> und static inline Funktionen.
Geändert in Version 3.7: Thread-Unterstützung und OpenSSL 1.0.2 sind nun erforderlich.
Geändert in Version 3.10: OpenSSL 1.1.1 ist nun erforderlich. SQLite 3.7.15 erforderlich.
Geändert in Version 3.11: C11-Compiler, IEEE 754 und NaN-Unterstützung sind nun erforderlich. Unter Windows ist Visual Studio 2017 oder neuer erforderlich. Tcl/Tk Version 8.5.12 ist nun für das Modul tkinter erforderlich.
Geändert in Version 3.13: Autoconf 2.71, aclocal 1.16.5 und SQLite 3.15.2 sind nun erforderlich.
Geändert in Version 3.14: Autoconf 2.72 ist nun erforderlich.
Siehe auch PEP 7 „Style Guide for C Code“ und PEP 11 „CPython platform support“.
3.2. Generierte Dateien¶
Um Build-Abhängigkeiten zu reduzieren, enthält der Python-Quellcode mehrere generierte Dateien. Befehle zum erneuten Generieren aller generierten Dateien
make regen-all
make regen-stdlib-module-names
make regen-limited-abi
make regen-configure
Die Datei Makefile.pre.in dokumentiert generierte Dateien, ihre Eingaben und die zur Neuerstellung verwendeten Werkzeuge. Suchen Sie nach regen-* Make-Zielen.
3.2.1. configure Skript¶
Der Befehl make regen-configure generiert die Datei aclocal.m4 und das Skript configure mithilfe des Shell-Skripts Tools/build/regen-configure.sh, das einen Ubuntu-Container verwendet, um dieselben Tool-Versionen zu erhalten und ein reproduzierbares Ergebnis zu erzielen.
Der Container ist optional, der folgende Befehl kann lokal ausgeführt werden
autoreconf -ivf -Werror
Die generierten Dateien können je nach genauen Versionen von autoconf-archive, aclocal und pkg-config variieren.
3.3. Configure-Optionen¶
Alle Optionen des configure-Skripts auflisten mit
./configure --help
Siehe auch die Datei Misc/SpecialBuilds.txt in der Python-Quellcode-Distribution.
3.3.1. Allgemeine Optionen¶
- --enable-loadable-sqlite-extensions¶
Unterstützung für ladbare Erweiterungen im Modul
_sqlite(Standard ist nein) des Modulssqlite3.Siehe die Methode
sqlite3.Connection.enable_load_extension()des Modulssqlite3.Hinzugefügt in Version 3.6.
- --disable-ipv6¶
Deaktiviert die IPv6-Unterstützung (standardmäßig aktiviert, wenn unterstützt), siehe das Modul
socket.
- --enable-big-digits=[15|30]¶
Definiert die Größe in Bits von Python
int-Ziffern: 15 oder 30 Bits.Standardmäßig ist die Zifferngröße 30.
Definiert
PYLONG_BITS_IN_DIGITauf15oder30.Siehe
sys.int_info.bits_per_digit.
- --with-suffix=SUFFIX¶
Setzt das Suffix der Python-Executable auf SUFFIX.
Das Standardsuffix ist
.exeunter Windows und macOS (python.exe-Executable),.jsunter Emscripten Node,.htmlunter Emscripten Browser,.wasmunter WASI und eine leere Zeichenkette auf anderen Plattformen (python-Executable).Geändert in Version 3.11: Das Standardsuffix auf der WASM-Plattform ist eines von
.js,.htmloder.wasm.
- --with-tzpath=<Liste von absoluten Pfaden, getrennt durch pathsep>¶
Wählt den Standard-Zeitzonen-Suchpfad für
zoneinfo.TZPATH. Siehe die Kompilierungszeitkonfiguration des Modulszoneinfo.Standard:
/usr/share/zoneinfo:/usr/lib/zoneinfo:/usr/share/lib/zoneinfo:/etc/zoneinfo.Siehe den Pfadtrennzeichen
os.pathsep.Hinzugefügt in Version 3.9.
- --without-decimal-contextvar¶
Erstellt das Modul
_decimalunter Verwendung eines Thread-lokalen Kontexts anstelle eines Coroutine-lokalen Kontexts (Standard), siehe das Moduldecimal.Siehe
decimal.HAVE_CONTEXTVARund das Modulcontextvars.Hinzugefügt in Version 3.9.
- --with-dbmliborder=<Liste von Backend-Namen>¶
Überschreibt die Reihenfolge, in der db-Backends für das Modul
dbmgeprüft werden.Ein gültiger Wert ist eine durch Doppelpunkte (
:) getrennte Zeichenkette mit den Backend-Namenndbm;gdbm;bdb.
- --without-c-locale-coercion¶
Deaktiviert die C-Locale-Konvertierung in eine UTF-8-basierte Locale (standardmäßig aktiviert).
Definiert nicht das Makro
PY_COERCE_C_LOCALE.Siehe
PYTHONCOERCECLOCALEund die PEP 538.
- --with-platlibdir=DIRNAME¶
Verzeichnisname für Python-Bibliotheken (Standard ist
lib).Fedora und SuSE verwenden
lib64auf 64-Bit-Plattformen.Siehe
sys.platlibdir.Hinzugefügt in Version 3.9.
- --with-wheel-pkg-dir=PATH¶
Verzeichnis für Wheel-Pakete, die vom Modul
ensurepipverwendet werden (standardmäßig keine).Einige Linux-Distributionen empfehlen aus Gründen der Paketierung, keine Abhängigkeiten zu bündeln. Zum Beispiel installiert Fedora Wheel-Pakete im Verzeichnis
/usr/share/python-wheels/und installiert das Paketensurepip._bundlednicht.Hinzugefügt in Version 3.10.
- --with-pkg-config=[check|yes|no]¶
Gibt an, ob configure pkg-config zur Erkennung von Build-Abhängigkeiten verwenden soll.
check(Standard): pkg-config ist optionalyes: pkg-config ist zwingend erforderlichno: configure verwendet pkg-config nicht, auch wenn es vorhanden ist
Hinzugefügt in Version 3.11.
- --enable-pystats¶
Aktiviert die Erfassung interner Python-Performance-Statistiken.
Standardmäßig ist die Erfassung von Statistiken deaktiviert. Verwenden Sie den Befehl
python3 -X pystatsoder setzen Sie die UmgebungsvariablePYTHONSTATS=1, um die Erfassung von Statistiken beim Python-Start zu aktivieren.Beim Beenden von Python werden Statistiken ausgegeben, wenn die Erfassung aktiviert und nicht gelöscht wurde.
Auswirkungen
Fügt die Befehlszeilenoption
-X pystatshinzu.Fügt die Umgebungsvariable
PYTHONSTATShinzu.Definiert das Makro
Py_STATS.Fügt Funktionen zum Modul
syshinzusys._stats_on(): Aktiviert die Erfassung von Statistiken.sys._stats_off(): Deaktiviert die Erfassung von Statistiken.sys._stats_clear(): Löscht die Statistiken.sys._stats_dump(): Gibt Statistiken in eine Datei aus und löscht die Statistiken.
Die Statistiken werden in eine beliebige (wahrscheinlich eindeutige) Datei in
/tmp/py_stats/(Unix) oderC:\temp\py_stats\(Windows) ausgegeben. Wenn dieses Verzeichnis nicht existiert, werden die Ergebnisse auf stderr ausgegeben.Verwenden Sie
Tools/scripts/summarize_stats.py, um die Statistiken zu lesen.Statistiken
Opcodes
Spezialisierung: Erfolg, Fehler, Treffer, aufgeschoben, verpasst, deopt, Fehler;
Ausführungszähler;
Paarzähler.
Aufruf
Inlinierte Python-Aufrufe;
PyEval-Aufrufe;
Frames verschoben;
Frame-Objekt erstellt;
Eval-Aufrufe: Vektor, Generator, Legacy, Funktion VECTORCALL, Klasse erstellen, Slot, Funktion „ex“, API, Methode.
Objekt
Incref und decref;
Interpreter Incref und decref;
Allokationen: alle, 512 Bytes, 4 KiB, groß;
frei;
zu/von freien Listen;
Wörterbuch materialisiert/dematerialisiert;
Typ-Cache;
Optimierungsversuche;
Optimierungsspuren erstellt/ausgeführt;
Uops ausgeführt.
Garbage Collector
Garbage Collections;
Objekte besucht;
Objekte gesammelt.
Hinzugefügt in Version 3.11.
- --disable-gil¶
Aktiviert die Unterstützung für die Ausführung von Python ohne den Global Interpreter Lock (GIL): Freier Threading-Build.
Definiert das Makro
Py_GIL_DISABLEDund fügt"t"zusys.abiflagshinzu.Weitere Details finden Sie unter Free-threaded CPython.
Hinzugefügt in Version 3.13.
- --enable-experimental-jit=[no|yes|yes-off|interpreter]¶
Gibt an, wie der experimentelle Just-In-Time Compiler integriert werden soll.
no: Baut die JIT nicht.yes: Aktiviert die JIT. Um sie zur Laufzeit zu deaktivieren, setzen Sie die UmgebungsvariablePYTHON_JIT=0.yes-off: Baut die JIT, deaktiviert sie aber standardmäßig. Um sie zur Laufzeit zu aktivieren, setzen Sie die UmgebungsvariablePYTHON_JIT=1.interpreter: Aktiviert den „JIT-Interpreter“ (nur nützlich für Debugger der JIT selbst). Um ihn zur Laufzeit zu deaktivieren, setzen Sie die UmgebungsvariablePYTHON_JIT=0.
--enable-experimental-jit=noist das Standardverhalten, wenn die Option nicht angegeben wird, und--enable-experimental-jitist eine Kurzform für--enable-experimental-jit=yes. Weitere Informationen finden Sie inTools/jit/README.md, einschließlich der Installation der erforderlichen Build-Abhängigkeiten.Hinweis
Stellen Sie beim Erstellen von CPython mit aktivierter JIT sicher, dass Ihr System Python 3.11 oder neuer installiert hat.
Hinzugefügt in Version 3.13.
- PKG_CONFIG¶
Pfad zum
pkg-config-Dienstprogramm.
- PKG_CONFIG_LIBDIR¶
- PKG_CONFIG_PATH¶
pkg-config-Optionen.
3.3.2. C-Compiler-Optionen¶
- CC¶
C-Compiler-Befehl.
- CFLAGS¶
C-Compiler-Flags.
- CPP¶
C-Präprozessor-Befehl.
- CPPFLAGS¶
C-Präprozessor-Flags, z.B.
-Iinclude_dir.
3.3.3. Linker-Optionen¶
- LDFLAGS¶
Linker-Flags, z.B.
-Llibrary_directory.
- LIBS¶
Bibliotheken, die an den Linker übergeben werden, z.B.
-llibrary.
- MACHDEP¶
Name für maschinenabhängige Bibliotheksdateien.
3.3.4. Optionen für Drittanbieter-Abhängigkeiten¶
Hinzugefügt in Version 3.11.
- BZIP2_CFLAGS¶
- BZIP2_LIBS¶
C-Compiler- und Linker-Flags, um Python mit
libbz2zu verlinken, verwendet vom Modulbz2, überschreibtpkg-config.
- CURSES_CFLAGS¶
- CURSES_LIBS¶
C-Compiler- und Linker-Flags für
libncursesoderlibncursesw, verwendet vom Modulcurses, überschreibtpkg-config.
- GDBM_CFLAGS¶
- GDBM_LIBS¶
C-Compiler- und Linker-Flags für
gdbm.
- LIBB2_CFLAGS¶
- LIBB2_LIBS¶
C-Compiler- und Linker-Flags für
libb2(BLAKE2), verwendet vom Modulhashlib, überschreibtpkg-config.
- LIBEDIT_CFLAGS¶
- LIBEDIT_LIBS¶
C-Compiler- und Linker-Flags für
libedit, verwendet vom Modulreadline, überschreibtpkg-config.
- LIBFFI_CFLAGS¶
- LIBFFI_LIBS¶
C-Compiler- und Linker-Flags für
libffi, verwendet vom Modulctypes, überschreibtpkg-config.
- LIBMPDEC_CFLAGS¶
- LIBMPDEC_LIBS¶
C-Compiler- und Linker-Flags für
libmpdec, verwendet vomdecimal-Modul, überschreibtpkg-config.Hinweis
Diese Umgebungsvariablen haben keine Auswirkung, es sei denn,
--with-system-libmpdecwird angegeben.
- LIBLZMA_CFLAGS¶
- LIBLZMA_LIBS¶
C-Compiler- und Linker-Flags für
liblzma, verwendet vomlzma-Modul, überschreibtpkg-config.
- LIBREADLINE_CFLAGS¶
- LIBREADLINE_LIBS¶
C-Compiler- und Linker-Flags für
libreadline, verwendet vomreadline-Modul, überschreibtpkg-config.
- LIBSQLITE3_CFLAGS¶
- LIBSQLITE3_LIBS¶
C-Compiler- und Linker-Flags für
libsqlite3, verwendet vomsqlite3-Modul, überschreibtpkg-config.
- LIBUUID_CFLAGS¶
- LIBUUID_LIBS¶
C-Compiler- und Linker-Flags für
libuuid, verwendet vomuuid-Modul, überschreibtpkg-config.
- LIBZSTD_CFLAGS¶
- LIBZSTD_LIBS¶
C-Compiler- und Linker-Flags für
libzstd, verwendet vomcompression.zstd-Modul, überschreibtpkg-config.Hinzugefügt in Version 3.14.
- PANEL_CFLAGS¶
- PANEL_LIBS¶
C-Compiler- und Linker-Flags für PANEL, überschreibt
pkg-config.C-Compiler- und Linker-Flags für
libpaneloderlibpanelw, verwendet vomcurses.panel-Modul, überschreibtpkg-config.
- TCLTK_CFLAGS¶
- TCLTK_LIBS¶
C-Compiler- und Linker-Flags für TCLTK, überschreibt
pkg-config.
- ZLIB_CFLAGS¶
3.3.5. WebAssembly Optionen¶
- --enable-wasm-dynamic-linking¶
Dynamische Linkunterstützung für WASM aktivieren.
Dynamisches Linken aktiviert
dlopen. Die Dateigröße der ausführbaren Datei erhöht sich aufgrund eingeschränkter Totcode-Eliminierung und zusätzlicher Funktionen.Hinzugefügt in Version 3.11.
- --enable-wasm-pthreads¶
Pthreads-Unterstützung für WASM aktivieren.
Hinzugefügt in Version 3.11.
3.3.6. Installationsoptionen¶
- --prefix=PREFIX¶
Architekturunabhängige Dateien in PREFIX installieren. Unter Unix ist der Standardwert
/usr/local.Dieser Wert kann zur Laufzeit über
sys.prefixabgerufen werden.Als Beispiel kann
--prefix="$HOME/.local/"verwendet werden, um ein Python-System im Home-Verzeichnis zu installieren.
- --exec-prefix=EPREFIX¶
Architekturabhängige Dateien in EPREFIX installieren, Standard ist
--prefix.Dieser Wert kann zur Laufzeit über
sys.exec_prefixabgerufen werden.
- --disable-test-modules¶
Testmodule wie das
test-Paket oder das Erweiterungsmodul_testcapi(standardmäßig erstellt und installiert) nicht erstellen oder installieren.Hinzugefügt in Version 3.10.
- --with-ensurepip=[upgrade|install|no]¶
Wählen Sie den
ensurepip-Befehl, der bei der Python-Installation ausgeführt wirdupgrade(Standard): Führt den Befehlpython -m ensurepip --altinstall --upgradeaus.install: Führt den Befehlpython -m ensurepip --altinstallaus;no: Führt ensurepip nicht aus;
Hinzugefügt in Version 3.6.
3.3.7. Performance-Optionen¶
Für beste Leistung wird die Konfiguration von Python mit --enable-optimizations --with-lto (PGO + LTO) empfohlen. Die experimentelle Option --enable-bolt kann ebenfalls zur Leistungssteigerung verwendet werden.
- --enable-optimizations¶
Profilgesteuerte Optimierung (PGO) mit
PROFILE_TASKaktivieren (standardmäßig deaktiviert).Der C-Compiler Clang benötigt das Programm
llvm-profdatafür PGO. Unter macOS benötigt auch GCC dieses: GCC ist unter macOS nur ein Alias für Clang.Deaktiviert auch semantische Interposition in libpython, wenn
--enable-sharedverwendet wird und GCC zum Einsatz kommt: fügt-fno-semantic-interpositionzu den Compiler- und Linker-Flags hinzu.Hinweis
Während des Builds können Compiler-Warnungen bezüglich fehlender Profildaten für einige Quelldateien auftreten. Diese Warnungen sind harmlos, da nur ein Teil des Codes während der Erfassung der Profildaten ausgeführt wird. Um diese Warnungen bei Clang zu deaktivieren, unterdrücken Sie sie manuell, indem Sie
-Wno-profile-instr-unprofiledzuCFLAGShinzufügen.Hinzugefügt in Version 3.6.
Geändert in Version 3.10: Verwendet
-fno-semantic-interpositionunter GCC.
- PROFILE_TASK¶
Umgebungsvariable, die im Makefile verwendet wird: Python-Befehlszeilenargumente für die PGO-Generierungsaufgabe.
Standard:
-m test --pgo --timeout=$(TESTTIMEOUT).Hinzugefügt in Version 3.8.
Geändert in Version 3.13: Aufgabenfehler werden nicht mehr stillschweigend ignoriert.
- --with-lto=[full|thin|no|yes]¶
Link Time Optimization (LTO) in jedem Build aktivieren (standardmäßig deaktiviert).
Der C-Compiler Clang benötigt
llvm-arfür LTO (arunter macOS) sowie einen LTO-fähigen Linker (ld.goldoderlld).Hinzugefügt in Version 3.6.
Hinzugefügt in Version 3.11: Um die ThinLTO-Funktion zu verwenden, verwenden Sie
--with-lto=thinauf Clang.Geändert in Version 3.12: Verwendet ThinLTO als Standard-Optimierungsrichtlinie für Clang, wenn der Compiler das Flag akzeptiert.
- --enable-bolt¶
Verwendung des BOLT Post-Link-Binär-Optimierers aktivieren (standardmäßig deaktiviert).
BOLT ist Teil des LLVM-Projekts, aber nicht immer in deren Binärdistributionen enthalten. Dieses Flag erfordert, dass
llvm-boltundmerge-fdataverfügbar sind.BOLT ist immer noch ein recht neues Projekt, daher sollte dieses Flag vorerst als experimentell betrachtet werden. Da dieses Werkzeug auf Maschinencode operiert, hängt sein Erfolg von einer Kombination aus der Build-Umgebung, den anderen Optimierungs-Configure-Argumenten und der CPU-Architektur ab, und nicht alle Kombinationen werden unterstützt. BOLT-Versionen vor LLVM 16 stürzen BOLT unter bestimmten Szenarien bekanntermaßen ab. Die Verwendung von LLVM 16 oder neuer für BOLT-Optimierungen wird dringend empfohlen.
Die
BOLT_INSTRUMENT_FLAGSundBOLT_APPLY_FLAGSconfigure Variablen können definiert werden, um die Standardargumente für llvm-bolt beim Instrumentieren und Anwenden von BOLT-Daten auf Binärdateien zu überschreiben.Hinzugefügt in Version 3.12.
- BOLT_APPLY_FLAGS¶
Argumente für
llvm-boltbeim Erstellen einer BOLT-optimierten Binärdatei.Hinzugefügt in Version 3.12.
- BOLT_INSTRUMENT_FLAGS¶
Argumente für
llvm-boltbeim Instrumentieren von Binärdateien.Hinzugefügt in Version 3.12.
- --with-computed-gotos¶
Computed Gotas in der Auswertungs-Schleife aktivieren (standardmäßig auf unterstützten Compilern aktiviert).
- --with-tail-call-interp¶
Interpreter aktivieren, die Tail Calls in CPython verwenden. Wenn aktiviert, wird die Aktivierung von PGO (
--enable-optimizations) dringend empfohlen. Diese Option erfordert spezifisch einen C-Compiler mit ordnungsgemäßer Tail Call-Unterstützung und der preserve_none-Aufrufkonvention. Zum Beispiel unterstützt Clang 19 und neuer diese Funktion.Hinzugefügt in Version 3.14.
- --without-mimalloc¶
Den schnellen mimalloc-Allocator deaktivieren (standardmäßig aktiviert).
Siehe auch die Umgebungsvariable
PYTHONMALLOC.
- --without-pymalloc¶
Den spezialisierten Python-Speicher-Allocator pymalloc deaktivieren (standardmäßig aktiviert).
Siehe auch die Umgebungsvariable
PYTHONMALLOC.
- --without-doc-strings¶
Statische Dokumentationsstrings zur Reduzierung des Speicher-Footprints deaktivieren (standardmäßig aktiviert). In Python definierte Dokumentationsstrings sind nicht betroffen.
Das Makro
WITH_DOC_STRINGSnicht definieren.Siehe das Makro
PyDoc_STRVAR().
- --enable-profiling¶
C-Level-Code-Profiling mit
gprofaktivieren (standardmäßig deaktiviert).
- --with-strict-overflow¶
Fügt
-fstrict-overflowzu den C-Compiler-Flags hinzu (standardmäßig fügen wir stattdessen-fno-strict-overflowhinzu).
- --without-remote-debug¶
Deaktiviert die in PEP 768 beschriebene Remote-Debugging-Unterstützung (standardmäßig aktiviert). Wenn dieses Flag angegeben wird, wird der Code, der es dem Interpreter ermöglicht, die Ausführung einer Python-Datei in einem separaten Prozess gemäß PEP 768 zu planen, nicht kompiliert. Dies umfasst sowohl die Funktionalität zur Planung der Ausführung von Code als auch die Funktionalität zum Empfang von auszuführendem Code.
-
Py_REMOTE_DEBUG¶
Dieses Makro ist standardmäßig definiert, es sei denn, Python wird mit
--without-remote-debugkonfiguriert.Beachten Sie, dass Remote-Debugging möglicherweise nicht verfügbar ist (z. B. auf einer inkompatiblen Plattform), auch wenn das Makro definiert ist.
Hinzugefügt in Version 3.14.
-
Py_REMOTE_DEBUG¶
3.3.8. Python Debug Build¶
Ein Debug-Build ist ein Python, das mit der Konfigurationsoption --with-pydebug erstellt wurde.
Auswirkungen eines Debug-Builds
Alle Warnungen werden standardmäßig angezeigt: Die Liste der Standard-Warnungsfilter ist im
warnings-Modul leer.Fügt
dzusys.abiflagshinzu.Fügt die Funktion
sys.gettotalrefcount()hinzu.Fügt die Kommandozeilenoption
-X showrefcounthinzu.Fügt die Kommandozeilenoption
-dund die UmgebungsvariablePYTHONDEBUGhinzu, um den Parser zu debuggen.Unterstützung für die Variable
__lltrace__hinzufügen: Aktiviert Low-Level-Tracing in der Bytecode-Ausführungs-Schleife, wenn die Variable definiert ist.Installiert Debug-Hooks für Speicher-Allocatoren, um Pufferüberläufe und andere Speicherfehler zu erkennen.
Definiert die Makros
Py_DEBUGundPy_REF_DEBUG.Fügt Laufzeitprüfungen hinzu: Code, der von
#ifdef Py_DEBUGund#endifumschlossen ist. Aktiviertassert(...)und_PyObject_ASSERT(...)Assertions: Definiert nicht das MakroNDEBUG(siehe auch die Konfigurationsoption--with-assertions). HauptlaufzeitprüfungenFügt Integritätsprüfungen für Funktionsargumente hinzu.
Unicode- und Integer-Objekte werden mit einem Muster gefüllt, um die Verwendung von uninitialisierten Objekten zu erkennen.
Stellt sicher, dass Funktionen, die die aktuelle Ausnahme löschen oder ersetzen können, nicht mit einer ausgelösten Ausnahme aufgerufen werden.
Überprüft, ob Deallokatorfunktionen die aktuelle Ausnahme nicht ändern.
Der Garbage Collector (
gc.collect()-Funktion) führt grundlegende Überprüfungen auf Objektkonsistenz durch.Das Makro
Py_SAFE_DOWNCAST()prüft auf Integer-Unter- und -Überlauf beim Heruntercasting von breiten auf schmale Typen.
Siehe auch den Python Development Mode und die Konfigurationsoption --with-trace-refs.
Geändert in Version 3.8: Release- und Debug-Builds sind nun ABI-kompatibel: Die Definition des Makros Py_DEBUG impliziert nicht mehr das Makro Py_TRACE_REFS (siehe Option --with-trace-refs).
3.3.9. Debug-Optionen¶
- --with-pydebug¶
Python im Debug-Modus erstellen: Definiert das Makro
Py_DEBUG(standardmäßig deaktiviert).
- --with-trace-refs¶
Referenzen zum Debugging aktivieren (standardmäßig deaktiviert).
Auswirkungen
Definiert das Makro
Py_TRACE_REFS.Fügt die Funktion
sys.getobjects()hinzu.Fügt die Umgebungsvariable
PYTHONDUMPREFShinzu.
Die Umgebungsvariable
PYTHONDUMPREFSkann verwendet werden, um beim Beenden von Python noch lebende Objekte und Referenzzähler auszugeben.Statisch zugewiesene Objekte werden nicht verfolgt.
Hinzugefügt in Version 3.8.
Geändert in Version 3.13: Dieser Build ist nun ABI-kompatibel mit Release-Build und Debug-Build.
- --with-assertions¶
Build mit aktivierten C-Assertions (Standard ist nein):
assert(...);und_PyObject_ASSERT(...);.Wenn gesetzt, wird das Makro
NDEBUGnicht in der Compiler-VariablenOPTdefiniert.Siehe auch die Option
--with-pydebug(Debug-Build), die ebenfalls Assertions aktiviert.Hinzugefügt in Version 3.6.
- --with-valgrind¶
Valgrind-Unterstützung aktivieren (Standard ist nein).
- --with-dtrace¶
DTrace-Unterstützung aktivieren (Standard ist nein).
Siehe CPython mit DTrace und SystemTap instrumentieren.
Hinzugefügt in Version 3.6.
- --with-address-sanitizer¶
AddressSanitizer-Speicherfehlererkennung,
asan, aktivieren (Standard ist nein). Um die Erkennungsfähigkeiten von ASan zu verbessern, möchten Sie dies möglicherweise mit--without-pymallockombinieren, um den spezialisierten Allokator für kleine Objekte zu deaktivieren, dessen Allokationen von ASan nicht verfolgt werden.Hinzugefügt in Version 3.6.
- --with-memory-sanitizer¶
MemorySanitizer-Allokationsfehlererkennung,
msan, aktivieren (Standard ist nein).Hinzugefügt in Version 3.6.
- --with-undefined-behavior-sanitizer¶
UndefinedBehaviorSanitizer-Erkennung für undefiniertes Verhalten,
ubsan, aktivieren (Standard ist nein).Hinzugefügt in Version 3.6.
- --with-thread-sanitizer¶
ThreadSanitizer Datenrennen-Detektor aktivieren,
tsan(Standard ist nein).Hinzugefügt in Version 3.13.
3.3.10. Linker-Optionen¶
Aktiviert das Erstellen einer gemeinsam genutzten Python-Bibliothek:
libpython(Standard ist nein).
- --without-static-libpython¶
Erstellt
libpythonMAJOR.MINOR.anicht und installiertpython.onicht (standardmäßig erstellt und aktiviert).Hinzugefügt in Version 3.10.
3.3.11. Bibliotheksoptionen¶
- --with-libs='lib1 ...'¶
Linkt gegen zusätzliche Bibliotheken (Standard ist nein).
- --with-system-expat¶
Erstellt das Modul
pyexpatunter Verwendung einer installiertenexpat-Bibliothek (Standard ist nein).
- --with-system-libmpdec¶
Erstellt das Erweiterungsmodul
_decimalunter Verwendung einer installiertenmpdecimal-Bibliothek, siehe das Moduldecimal(Standard ist ja).Hinzugefügt in Version 3.3.
Geändert in Version 3.13: Standardmäßig wird die installierte
mpdecimal-Bibliothek verwendet.Veraltet seit Version 3.13, wird in Version 3.16 entfernt: Eine Kopie der Quelltexte der
mpdecimal-Bibliothek wird ab Python 3.16 nicht mehr mit Python verteilt.Siehe auch
- --with-readline=readline|editline¶
Gibt eine Backend-Bibliothek für das Modul
readlinean.readline: Verwendet readline als Backend.
editline: Verwendet editline als Backend.
Hinzugefügt in Version 3.10.
- --without-readline¶
Erstellt das Modul
readlinenicht (standardmäßig erstellt).Definiert das Makro
HAVE_LIBREADLINEnicht.Hinzugefügt in Version 3.10.
- --with-libm=STRING¶
Überschreibt die
libmMathematikbibliothek mit *STRING* (Standard ist systemabhängig).
- --with-libc=STRING¶
Überschreibt die
libcC-Bibliothek mit *STRING* (Standard ist systemabhängig).
- --with-openssl=DIR¶
Root des OpenSSL-Verzeichnisses.
Hinzugefügt in Version 3.7.
- --with-openssl-rpath=[no|auto|DIR]¶
Legt das Laufzeitbibliotheksverzeichnis (rpath) für OpenSSL-Bibliotheken fest
no(Standard): rpath nicht festlegen;auto: rpath aus--with-opensslundpkg-configautomatisch ermitteln;*DIR*: ein explizites rpath festlegen.
Hinzugefügt in Version 3.10.
3.3.12. Sicherheitsoptionen¶
- --with-hash-algorithm=[fnv|siphash13|siphash24]¶
Wählt den Hash-Algorithmus für die Verwendung in
Python/pyhash.caussiphash13(Standard);siphash24;fnv.
Hinzugefügt in Version 3.4.
Hinzugefügt in Version 3.11:
siphash13wird hinzugefügt und ist der neue Standard.
- --with-builtin-hashlib-hashes=md5,sha1,sha256,sha512,sha3,blake2¶
Eingebaute Hash-Module
md5;sha1;sha256;sha512;sha3(mit shake);blake2.
Hinzugefügt in Version 3.9.
- --with-ssl-default-suites=[python|openssl|STRING]¶
Überschreibt die Zeichenkette der OpenSSL-Standard-Cipher-Suiten
python(Standard): Python-bevorzugte Auswahl verwenden;openssl: OpenSSL-Standards unberührt lassen;*STRING*: eine benutzerdefinierte Zeichenkette verwenden
Siehe das Modul
ssl.Hinzugefügt in Version 3.7.
Geändert in Version 3.10: Die Einstellungen
pythonund *STRING* legen auch TLS 1.2 als Mindestprotokollversion fest.
- --disable-safety¶
Deaktiviert Compiler-Optionen, die von OpenSSF aus Sicherheitsgründen empfohlen werden und keinen Leistungsaufwand haben. Wenn diese Option nicht aktiviert ist, wird CPython basierend auf sicheren Compiler-Optionen ohne Leistungsverlust kompiliert. Wenn diese Option aktiviert ist, wird CPython nicht mit den unten aufgeführten Compiler-Optionen kompiliert.
Die folgenden Compiler-Optionen werden mit
--disable-safetydeaktiviert-fstack-protector-strong: Aktiviert Laufzeitprüfungen für Stack-basierte Pufferüberläufe.
-Wtrampolines: Aktiviert Warnungen zu Trampolinen, die ausführbare Stacks erfordern.
Hinzugefügt in Version 3.14.
- --enable-slower-safety¶
Aktiviert Compiler-Optionen, die von OpenSSF aus Sicherheitsgründen empfohlen werden und Leistungsaufwand erfordern. Wenn diese Option nicht aktiviert ist, wird CPython nicht basierend auf sicheren Compiler-Optionen mit Leistungsbeeinträchtigung kompiliert. Wenn diese Option aktiviert ist, wird CPython mit den unten aufgeführten Compiler-Optionen kompiliert.
Die folgenden Compiler-Optionen werden mit
--enable-slower-safetyaktiviert-D_FORTIFY_SOURCE=3: Fortify-Quellen mit Compiler- und Laufzeitprüfungen für unsichere libc-Nutzung und Pufferüberläufe.
Hinzugefügt in Version 3.14.
3.3.13. macOS-Optionen¶
Siehe Mac/README.rst.
- --enable-universalsdk¶
- --enable-universalsdk=SDKDIR¶
Erstellt einen universellen Binärbuild. *SDKDIR* gibt an, welches macOS SDK für den Build verwendet werden soll (Standard ist nein).
- --enable-framework¶
- --enable-framework=INSTALLDIR¶
Erstellt ein Python.framework anstelle einer traditionellen Unix-Installation. Optional gibt *INSTALLDIR* den Installationspfad an (Standard ist nein).
- --with-universal-archs=ARCH¶
Gibt die Art der zu erstellenden universellen Binärdatei an. Diese Option ist nur gültig, wenn
--enable-universalsdkgesetzt ist.Optionen
universal2(x86-64 und arm64);32-bit(PPC und i386);64-bit(PPC64 und x86-64);3-way(i386, PPC und x86-64);intel(i386 und x86-64);intel-32(i386);intel-64(x86-64);all(PPC, i386, PPC64 und x86-64).
Beachten Sie, dass die Werte für dieses Konfigurationselement **nicht** mit den Bezeichnern für universelle Binärräder unter macOS übereinstimmen. Einzelheiten zu den Paketierungsplattform-Kompatibilitätstags für macOS finden Sie im Python Packaging User Guide.
- --with-framework-name=FRAMEWORK¶
Gibt den Namen für das Python-Framework unter macOS an, nur gültig, wenn
--enable-frameworkgesetzt ist (Standard:Python).
- --with-app-store-compliance¶
- --with-app-store-compliance=PATCH-FILE¶
Die Python-Standardbibliothek enthält Zeichenketten, die bekanntermaßen Fehler in automatisierten Überprüfungstools auslösen, wenn sie zur Verteilung über die macOS- und iOS App Stores eingereicht werden. Wenn diese Option aktiviert ist, wird die Liste der Patches angewendet, die bekanntermaßen die App-Store-Konformität korrigieren. Eine benutzerdefinierte Patch-Datei kann ebenfalls angegeben werden. Diese Option ist standardmäßig deaktiviert.
Hinzugefügt in Version 3.13.
3.3.14. iOS-Optionen¶
Siehe iOS/README.rst.
- --enable-framework=INSTALLDIR¶
Erstellt ein Python.framework. Im Gegensatz zu macOS ist das Argument *INSTALLDIR*, das den Installationspfad angibt, obligatorisch.
- --with-framework-name=FRAMEWORK¶
Gibt den Namen für das Framework an (Standard:
Python).
3.3.15. Cross-Compiling-Optionen¶
Cross-Compiling, auch bekannt als Cross-Building, kann verwendet werden, um Python für eine andere CPU-Architektur oder Plattform zu erstellen. Cross-Compiling erfordert einen Python-Interpreter für die Build-Plattform. Die Version des Build-Pythons muss mit der Version des Cross-Compiling-Host-Pythons übereinstimmen.
- --build=BUILD¶
Konfiguriert das Erstellen auf BUILD, normalerweise von config.guess erraten.
- --host=HOST¶
Cross-Compiling zum Erstellen von Programmen, die auf HOST (Zielplattform) ausgeführt werden sollen
- --with-build-python=path/to/python¶
Pfad zum Erstellen der
python-Binärdatei für Cross-CompilingHinzugefügt in Version 3.11.
- CONFIG_SITE=file¶
Eine Umgebungsvariable, die auf eine Datei mit Konfigurationsüberschreibungen verweist.
Beispiel für eine config.site-Datei
# config.site-aarch64 ac_cv_buggy_getaddrinfo=no ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no
- HOSTRUNNER¶
Programm zum Ausführen von CPython für die Host-Plattform für Cross-Compilierung.
Hinzugefügt in Version 3.11.
Beispiel für Cross-Compilierung
CONFIG_SITE=config.site-aarch64 ../configure \
--build=x86_64-pc-linux-gnu \
--host=aarch64-unknown-linux-gnu \
--with-build-python=../x86_64/python
3.4. Python-Build-System¶
3.4.1. Hauptdateien des Build-Systems¶
configure.ac=>configure;Makefile.pre.in=>Makefile(erstellt vonconfigure);pyconfig.h(erstellt vonconfigure);Modules/Setup: C-Erweiterungen, die vom Makefile mithilfe des Shell-SkriptsModule/makesetuperstellt werden;
3.4.2. Haupt-Build-Schritte¶
C-Dateien (
.c) werden als Objektdateien (.o) kompiliert.Eine statische
libpython-Bibliothek (.a) wird aus Objektdateien erstellt.python.ound die statischelibpython-Bibliothek werden in das endgültigepython-Programm gelinkt.C-Erweiterungen werden vom Makefile erstellt (siehe
Modules/Setup).
3.4.3. Haupt-Makefile-Ziele¶
3.4.3.1. make¶
In den meisten Fällen reicht es aus, wenn Sie nach der Bearbeitung von Code oder dem Aktualisieren Ihres Checkouts von Upstream einfach make ausführen. Dies erstellt (gemäß Make-Semantik) das Standardziel, das erste in der Makefile definierte. Nach Konvention (auch im CPython-Projekt) ist dies normalerweise das Ziel all. Das configure-Skript erweitert eine autoconf-Variable, @DEF_MAKE_ALL_RULE@, um genau zu beschreiben, welche Ziele make all erstellen wird. Die drei Optionen sind
profile-opt(konfiguriert mit--enable-optimizations)build_wasm(ausgewählt, wenn die Host-Plattformwasm32-wasi*oderwasm32-emscriptenentspricht)build_all(konfiguriert, ohne explizit eine der anderen zu verwenden)
Abhängig von den neuesten Änderungen an den Quelldateien erstellt Make alle Ziele (Objektdateien und ausführbare Dateien) neu, die als veraltet gelten, und führt bei Bedarf auch erneut configure aus. Quellen-/Zielabhängigkeiten sind jedoch zahlreich und werden manuell gepflegt, sodass Make manchmal nicht alle notwendigen Informationen hat, um alle neu zu erstellenden Ziele korrekt zu erkennen. Abhängig davon, welche Ziele nicht neu erstellt werden, können verschiedene Probleme auftreten. Wenn Sie Build- oder Testprobleme haben, die Sie anderweitig nicht erklären können, sollte make clean && make die meisten Abhängigkeitsprobleme beheben, allerdings auf Kosten längerer Build-Zeiten.
3.4.3.2. make platform¶
Erstellt das Programm python, erstellt jedoch nicht die Standardbibliotheks-Erweiterungsmodule. Dies generiert eine Datei namens platform, die eine einzelne Zeile mit Details zur Build-Plattform enthält, z. B. macosx-14.3-arm64-3.12 oder linux-x86_64-3.13.
3.4.3.3. make profile-opt¶
Baut Python mit Profil-gesteuerter Optimierung (PGO). Sie können die Konfigurationsoption --enable-optimizations verwenden, um dies zum Standardziel des Befehls make zu machen (make all oder einfach make).
3.4.3.4. make clean¶
Entfernt kompilierte Dateien.
3.4.3.5. make distclean¶
Zusätzlich zur Arbeit von make clean werden Dateien entfernt, die vom configure-Skript erstellt wurden. configure muss erneut ausgeführt werden, bevor erneut kompiliert werden kann. [1]
3.4.3.6. make install¶
Baut das Ziel all und installiert Python.
3.4.3.7. make test¶
Baut das Ziel all und führt die Python-Testsuite mit der Option --fast-ci ohne GUI-Tests aus. Variablen
TESTOPTS: zusätzliche Kommandozeilenoptionen für regrtest.TESTPYTHONOPTS: zusätzliche Python-Kommandozeilenoptionen.TESTTIMEOUT: Zeitlimit in Sekunden (Standard: 10 Minuten).
3.4.3.8. make ci¶
Dies ähnelt make test, verwendet jedoch -ugui, um auch GUI-Tests auszuführen.
Hinzugefügt in Version 3.14.
3.4.3.9. make buildbottest¶
Dies ähnelt make test, verwendet jedoch die Option --slow-ci und ein Standard-Zeitlimit von 20 Minuten anstelle der Option --fast-ci.
3.4.3.10. make regen-all¶
Generiert (fast) alle generierten Dateien neu. Dazu gehören (aber nicht ausschließlich) Bytecode-Fälle und die Parser-Generator-Datei. make regen-stdlib-module-names und autoconf müssen für die verbleibenden generierten Dateien separat ausgeführt werden.
3.4.4. C-Erweiterungen¶
Einige C-Erweiterungen werden als eingebaute Module kompiliert, wie z. B. das Modul sys. Sie werden mit dem Makro Py_BUILD_CORE_BUILTIN kompiliert. Eingebaute Module haben kein Attribut __file__
>>> import sys
>>> sys
<module 'sys' (built-in)>
>>> sys.__file__
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'sys' has no attribute '__file__'
Andere C-Erweiterungen werden als dynamische Bibliotheken kompiliert, wie z. B. das Modul _asyncio. Sie werden mit dem Makro Py_BUILD_CORE_MODULE kompiliert. Beispiel unter Linux x86-64
>>> import _asyncio
>>> _asyncio
<module '_asyncio' from '/usr/lib64/python3.9/lib-dynload/_asyncio.cpython-39-x86_64-linux-gnu.so'>
>>> _asyncio.__file__
'/usr/lib64/python3.9/lib-dynload/_asyncio.cpython-39-x86_64-linux-gnu.so'
Modules/Setup wird verwendet, um Makefile-Ziele zum Erstellen von C-Erweiterungen zu generieren. Am Anfang der Dateien werden C-Erweiterungen als eingebaute Module kompiliert. Erweiterungen, die nach der Markierung *shared* definiert sind, werden als dynamische Bibliotheken kompiliert.
Die Makros PyAPI_FUNC(), PyAPI_DATA() und PyMODINIT_FUNC aus Include/exports.h werden unterschiedlich definiert, je nachdem, ob das Makro Py_BUILD_CORE_MODULE definiert ist
Verwenden Sie
Py_EXPORTED_SYMBOL, wenn das MakroPy_BUILD_CORE_MODULEdefiniert ist.Andernfalls verwenden Sie
Py_IMPORTED_SYMBOL.
Wenn das Makro Py_BUILD_CORE_BUILTIN versehentlich auf eine als Shared Library kompilierte C-Erweiterung angewendet wird, wird ihre Funktion PyInit_xxx() nicht exportiert, was beim Import zu einem ImportError führt.
3.5. Compiler- und Linker-Flags¶
Optionen, die vom Skript ./configure und Umgebungsvariablen festgelegt und von Makefile verwendet werden.
3.5.1. Präprozessor-Flags¶
- CONFIGURE_CPPFLAGS¶
Wert der Variable
CPPFLAGS, der an das Skript./configureübergeben wird.Hinzugefügt in Version 3.6.
- CPPFLAGS¶
(Objective-) C/C++-Präprozessor-Flags, z. B.
-Iinclude_dir, wenn Sie Header in einem nicht standardmäßigen Verzeichnis include_dir haben.Sowohl
CPPFLAGSals auchLDFLAGSmüssen den Shell-Wert enthalten, um Erweiterungsmodule unter Verwendung der in den Umgebungsvariablen angegebenen Verzeichnisse erstellen zu können.
- BASECPPFLAGS¶
Hinzugefügt in Version 3.4.
- PY_CPPFLAGS¶
Zusätzliche Präprozessor-Flags, die zum Kompilieren der Interpreter-Objektdateien hinzugefügt werden.
Standard:
$(BASECPPFLAGS) -I. -I$(srcdir)/Include $(CONFIGURE_CPPFLAGS) $(CPPFLAGS).Hinzugefügt in Version 3.2.
3.5.2. Compiler-Flags¶
- CC¶
C-Compiler-Befehl.
Beispiel:
gcc -pthread.
- CXX¶
C++ Compiler-Befehl.
Beispiel:
g++ -pthread.
- CFLAGS¶
C-Compiler-Flags.
- CFLAGS_NODIST¶
CFLAGS_NODISTwird zum Kompilieren des Interpreters und der stdlib C-Erweiterungen verwendet. Verwenden Sie es, wenn ein Compiler-Flag **nicht** Teil vonCFLAGSsein soll, nachdem Python installiert wurde (gh-65320).Insbesondere sollte
CFLAGSnichtdas Compiler-Flag
-I(zum Festlegen des Suchpfads für Include-Dateien) enthalten. Die-I-Flags werden von links nach rechts verarbeitet, und alle Flags inCFLAGShätten Vorrang vor von Benutzern und Paketen bereitgestellten-I-Flags.Härtungs-Flags wie
-Werrorenthalten, da Distributionen nicht kontrollieren können, ob von Benutzern installierte Pakete solchen erhöhten Standards entsprechen.
Hinzugefügt in Version 3.5.
- COMPILEALL_OPTS¶
Optionen, die an die Befehlszeile
compileallübergeben werden, wenn PYC-Dateien inmake installerstellt werden. Standard:-j0.Hinzugefügt in Version 3.12.
- EXTRA_CFLAGS¶
Zusätzliche C-Compiler-Flags.
- CONFIGURE_CFLAGS¶
Wert der Variable
CFLAGS, die an das Skript./configureübergeben wird.Hinzugefügt in Version 3.2.
- CONFIGURE_CFLAGS_NODIST¶
Wert der Variable
CFLAGS_NODIST, die an das Skript./configureübergeben wird.Hinzugefügt in Version 3.5.
- BASECFLAGS¶
Basis-Compiler-Flags.
- OPT¶
Optimierungs-Flags.
- CFLAGS_ALIASING¶
Strikte oder nicht-strikte Aliasing-Flags, die zum Kompilieren von
Python/dtoa.cverwendet werden.Hinzugefügt in Version 3.7.
- CCSHARED¶
Compiler-Flags, die zum Erstellen einer Shared Library verwendet werden.
Zum Beispiel wird
-fPICunter Linux und BSD verwendet.
- CFLAGSFORSHARED¶
Zusätzliche C-Flags, die beim Erstellen der Interpreter-Objektdateien hinzugefügt werden.
Standard:
$(CCSHARED), wenn--enable-sharedverwendet wird, andernfalls eine leere Zeichenkette.
- PY_CFLAGS¶
Standard:
$(BASECFLAGS) $(OPT) $(CONFIGURE_CFLAGS) $(CFLAGS) $(EXTRA_CFLAGS).
- PY_CFLAGS_NODIST¶
Standard:
$(CONFIGURE_CFLAGS_NODIST) $(CFLAGS_NODIST) -I$(srcdir)/Include/internal.Hinzugefügt in Version 3.5.
- PY_STDMODULE_CFLAGS¶
C-Flags, die zum Erstellen der Interpreter-Objektdateien verwendet werden.
Standard:
$(PY_CFLAGS) $(PY_CFLAGS_NODIST) $(PY_CPPFLAGS) $(CFLAGSFORSHARED).Hinzugefügt in Version 3.7.
- PY_CORE_CFLAGS¶
Standard:
$(PY_STDMODULE_CFLAGS) -DPy_BUILD_CORE.Hinzugefügt in Version 3.2.
- PY_BUILTIN_MODULE_CFLAGS¶
Compiler-Flags zum Erstellen eines Standardbibliotheken-Erweiterungsmoduls als eingebautes Modul, wie das
posix-Modul.Standard:
$(PY_STDMODULE_CFLAGS) -DPy_BUILD_CORE_BUILTIN.Hinzugefügt in Version 3.8.
- PURIFY¶
Purify-Befehl. Purify ist ein Speicherdebug-Programm.
Standard: leere Zeichenkette (nicht verwendet).
3.5.3. Linker-Flags¶
- LINKCC¶
Linker-Befehl, der zum Erstellen von Programmen wie
pythonund_testembedverwendet wird.Standard:
$(PURIFY) $(CC).
- CONFIGURE_LDFLAGS¶
Wert der Variable
LDFLAGS, die an das Skript./configureübergeben wird.Vermeiden Sie die Zuweisung von
CFLAGS,LDFLAGSusw., damit Benutzer sie auf der Befehlszeile verwenden können, um diese Werte anzuhängen, ohne die voreingestellten Werte zu überschreiben.Hinzugefügt in Version 3.2.
- LDFLAGS_NODIST¶
LDFLAGS_NODISTwird auf die gleiche Weise wieCFLAGS_NODISTverwendet. Verwenden Sie es, wenn ein Linker-Flag *nicht* Teil vonLDFLAGSsein soll, sobald Python installiert ist (gh-65320).Insbesondere sollte
LDFLAGSnichtdas Compiler-Flag
-L(zum Festlegen des Suchpfads für Bibliotheken) enthalten. Die-L-Flags werden von links nach rechts verarbeitet, und alle Flags inLDFLAGShätten Vorrang vor von Benutzern und Paketen bereitgestellten-L-Flags.
- CONFIGURE_LDFLAGS_NODIST¶
Wert der Variable
LDFLAGS_NODIST, die an das Skript./configureübergeben wird.Hinzugefügt in Version 3.8.
- LDFLAGS¶
Linker-Flags, z. B.
-Llib_dir, wenn Sie Bibliotheken in einem nicht standardmäßigen Verzeichnis lib_dir haben.Sowohl
CPPFLAGSals auchLDFLAGSmüssen den Wert der Shell enthalten, um Erweiterungsmodule unter Verwendung der in den Umgebungsvariablen angegebenen Verzeichnisse erstellen zu können.
- LIBS¶
Linker-Flags, die Bibliotheken an den Linker übergeben, wenn die Python-Executable gelinkt wird.
Beispiel:
-lrt.
- LDSHARED¶
Befehl zum Erstellen einer Shared Library.
Standard:
@LDSHARED@ $(PY_LDFLAGS).
- BLDSHARED¶
Befehl zum Erstellen der Shared Library
libpython.Standard:
@BLDSHARED@ $(PY_CORE_LDFLAGS).
- PY_LDFLAGS¶
Standard:
$(CONFIGURE_LDFLAGS) $(LDFLAGS).
- PY_LDFLAGS_NODIST¶
Standard:
$(CONFIGURE_LDFLAGS_NODIST) $(LDFLAGS_NODIST).Hinzugefügt in Version 3.8.
- PY_CORE_LDFLAGS¶
Linker-Flags, die zum Erstellen der Interpreter-Objektdateien verwendet werden.
Hinzugefügt in Version 3.8.
Fußnoten