Eingebaute Optionen
Meson bietet zwei Arten von Optionen: Build-Optionen, die von den Build-Dateien bereitgestellt werden und eingebaute Optionen, die entweder universelle Optionen, Basisoptionen oder Compiler-Optionen sind.
Universelle Optionen
Alle diese können gesetzt werden, indem -Doption=value an meson (auch meson setup genannt) übergeben wird, oder indem sie innerhalb von default_options von project() in Ihrer meson.build gesetzt werden. Einige Optionen können auch über --option=value oder --option value gesetzt werden – eine Liste wird durch Ausführen von meson setup --help angezeigt.
Aus Gründen der Abwärtskompatibilität ist --warnlevel das CLI-Argument für die Option warning_level.
Sie können auch nach der Einrichtung mit meson configure -Doption=value bearbeitet werden.
Installationsoptionen sind normalerweise relativ zum Präfix, aber darauf sollte man sich nicht verlassen, da sie in den folgenden Fällen absolute Pfade sein können
- Wenn das Präfix
/usrist:sysconfdirhat standardmäßig/etc,localstatedirhat standardmäßig/varundsharedstatedirhat standardmäßig/var/lib - Wenn das Präfix
/usr/localist:localstatedirhat standardmäßig/var/localundsharedstatedirhat standardmäßig/var/local/lib - Wenn ein absoluter Pfad außerhalb des Präfixes vom Benutzer/Distributor angegeben wird.
Verzeichnisse
| Option | Standardwert | Beschreibung |
|---|---|---|
| prefix | siehe unten | Installationspräfix |
| bindir | bin | Verzeichnis für ausführbare Programme |
| datadir | share | Verzeichnis für Datendateien |
| includedir | include | Verzeichnis für Header-Dateien |
| infodir | share/info | Verzeichnis für Info-Seiten |
| libdir | siehe unten | Verzeichnis für Bibliotheken |
| licensedir | siehe unten | Verzeichnis für Lizenzen (seit 1.1.0) |
| libexecdir | libexec | Verzeichnis für Bibliotheks-Executable |
| localedir | share/locale | Verzeichnis für Locale-Daten |
| localstatedir | var | Verzeichnis für lokale Zustandsdaten |
| mandir | share/man | Verzeichnis für Handbuchseiten |
| sbindir | sbin | Verzeichnis für System-Executable |
| sharedstatedir | com | Architekturunabhängiges Datenverzeichnis |
| sysconfdir | etc | Sysconf-Datenverzeichnis |
prefix hat unter Windows standardmäßig C:/, ansonsten /usr/local. Sie sollten diesen Wert immer überschreiben.
libdir wird automatisch basierend auf Ihrer Plattform erkannt. Es sollte korrekt sein, wenn Sie "native" (Build-Maschine == Host-Maschine) Kompilierung durchführen. Für Cross-Kompilierungen versucht Meson, das korrekte libdir zu erraten, aber es ist möglicherweise nicht genau, insbesondere unter Linux, wo verschiedene Distributionen unterschiedliche Standardwerte haben. Die Verwendung einer Cross-Datei, insbesondere des Pfadabschnitts, kann notwendig sein.
licensedir ist standardmäßig leer. Wenn gesetzt, definiert es den Standardpfad für die Installation eines Abhängigkeitsmanifests und von Projektlizenzen. Weitere Details finden Sie unter meson.install_dependency_manifest().
Kernoptionen
Optionen, die in der Tabelle als "pro Maschine" gekennzeichnet sind, werden pro Maschine gesetzt. Details finden Sie im Abschnitt Optionen pro Maschine angeben.
| Option | Standardwert | Beschreibung | Ist pro Maschine | Ist pro Unterprojekt |
|---|---|---|---|---|
| auto_features {enabled, disabled, auto} | auto | Überschreibt den Wert aller 'auto'-Features | no | no |
| backend {ninja, vs, vs2010, vs2012, vs2013, vs2015, vs2017, vs2019, vs2022, xcode, none} |
ninja | Zu verwendendes Backend | no | no |
| genvslite {vs2022} | vs2022 | Richtet mehrere Ninja-Build-Verzeichnisse mit Multi-Builttype und eine Visual Studio-Lösung ein | no | no |
| buildtype {plain, debug, debugoptimized, release, minsize, custom} |
debug | Zu verwendender Build-Typ | no | no |
| debug | true | Aktiviert Debug-Symbole und andere Informationen | no | no |
| default_both_libraries {shared, static, auto} | shared | Standard-Bibliothekstyp für both_libraries | no | no |
| default_library {shared, static, both} | shared | Standard-Bibliothekstyp | no | yes |
| errorlogs | true | Ob Protokolle von fehlgeschlagenen Tests ausgegeben werden sollen. | no | no |
| install_umask {preserve, 0000-0777} | 022 | Standard-Umask, die auf die Berechtigungen installierter Dateien angewendet wird | no | no |
| layout {mirror,flat} | mirror | Build-Verzeichnislayout | no | no |
| optimization {plain, 0, g, 1, 2, 3, s} | 0 | Optimierungsstufe | no | no |
| pkg_config_path {OS-getrennter Pfad} | '' | Zusätzliche Pfade, die pkg-config vor den integrierten Pfaden durchsuchen soll | yes | no |
| prefer_static | false | Ob statisches Linken vor dynamischem Linken versucht werden soll | no | no |
| cmake_prefix_path | [] | Zusätzliche Präfixe, die CMake vor den integrierten Pfaden durchsuchen soll | yes | no |
| stdsplit | true | Teilt stdout und stderr in Testprotokollen auf | no | no |
| strip | false | Bereinigt Targets bei der Installation | no | no |
| unity {on, off, subprojects} | off | Unity-Build | no | no |
| unity_size {>=2} | 4 | Unity-Dateiblockgröße | no | no |
| warning_level {0, 1, 2, 3, everything} | 1 | Legt die Warnstufe fest. Von 0 = Compiler-Standard bis alles = höchste | no | yes |
| werror | false | Behandelt Warnungen als Fehler | no | yes |
| wrap_mode {default, nofallback, nodownload, forcefallback, nopromote} |
default | Zu verwendender Wrap-Modus | no | no |
| force_fallback_for | [] | Erzwingt Fallback für diese Abhängigkeiten | no | no |
| vsenv | false | Aktiviert die Visual Studio-Umgebung | no | no |
Details für backend
Mehrere Build-Dateiformate werden als Kommandoausführer unterstützt, um das konfigurierte Projekt zu erstellen. Meson bevorzugt standardmäßig ninja, aber plattformspezifische Backends sind auch für eine bessere IDE-Integration mit nativen Werkzeugen verfügbar: Visual Studio für Windows und xcode für macOS. Es ist auch möglich, mit keinem Backend zu konfigurieren, was ein Fehler ist, wenn Sie zu bauende Ziele haben, aber für Projekte, die Konfiguration, Testen und Installation benötigen, eine leichtere automatisierte Build-Pipeline ermöglicht.
Details für genvslite
Richtet mehrere Build-Verzeichnisse mit Buildtyp-Suffix und Ninja-Backend ein (z. B. [Buildverzeichnis]_[debug/release/etc.]) und generiert [Buildverzeichnis]_vs, das eine Visual Studio-Lösung enthält, die eine Meson-Kompilierung der eingerichteten Build-Verzeichnisse aufruft, wie es für die aktuelle Konfiguration (Buildtyp) angemessen ist.
Dies hat den Effekt einer einfachen Einrichtungs-Makro von mehreren 'meson setup ...'-Aufrufen mit einer Reihe von verschiedenen Buildtyp-Werten. Zum Beispiel: meson setup ... --genvslite vs2022 somebuilddir führt Folgendes aus –
meson setup ... --backend ninja --buildtype debug somebuilddir_debug
meson setup ... --backend ninja --buildtype debugoptimized somebuilddir_debugoptimized
meson setup ... --backend ninja --buildtype release somebuilddir_release
und erstellt zusätzlich ein weiteres Verzeichnis 'somebuilddir_vs', das eine generierte Multi-Konfigurations-Visual Studio-Lösung und Projekt(e) enthält, die mit dem entsprechenden somebuilddir_[...] für die ausgewählte Buildtyp-Konfiguration der Lösung konfiguriert sind, um zu bauen/kompilieren.
Details für buildtype
Zum Festlegen von Optimierungsstufen und Umschalten von Debug können Sie entweder die Option buildtype festlegen oder die Optionen optimization und debug festlegen, die eine feinere Steuerung über dieselben bieten. Was auch immer Sie verwenden, das andere wird davon abgeleitet. Zum Beispiel ist -Dbuildtype=debugoptimized dasselbe wie -Ddebug=true -Doptimization=2 und umgekehrt. Diese Tabelle dokumentiert die Zwei-Wege-Zuordnung
| buildtype | debug | optimization |
|---|---|---|
| plain | false | plain |
| debug | true | 0 |
| debugoptimized | true | 2 |
| release | false | 3 |
| minsize | true | s |
Alle anderen Kombinationen von debug und optimization setzen buildtype auf 'custom'.
Details für warning_level
Exakte Flags pro Warnstufe sind compilerspezifisch, aber es gibt eine ungefähre Tabelle für die gängigsten Compiler.
| Warnstufe | GCC/Clang | MSVC |
|---|---|---|
| 0 | ||
| 1 | -Wall | /W2 |
| 2 | -Wall -Wextra | /W3 |
| 3 | -Wall -Wextra -Wpedantic | /W4 |
| everything | -Weverything | /Wall |
Clangs -Weverything wird auf GCC emuliert, indem alle bekannten Warnungsflags übergeben werden.
Details für vsenv
Das Argument --vsenv wird seit 0.60.0 unterstützt, die Syntax -Dvsenv=true seit 1.1.0.
Seit 0.59.0 aktiviert Meson unter Windows automatisch eine Visual Studio-Umgebung für alle seine Unterbefehle, aber nur, wenn keine anderen Compiler (z. B. gcc oder clang) gefunden werden, und fährt stillschweigend fort, wenn die Aktivierung von Visual Studio fehlschlägt.
Das Setzen der Option vsenv auf true erzwingt die Aktivierung von Visual Studio auch dann, wenn andere Compiler gefunden werden. Es führt auch dazu, dass Meson mit einer Fehlermeldung abbricht, wenn die Aktivierung fehlschlägt.
vsenv ist standardmäßig true, wenn das vs-Backend verwendet wird.
Details für default_both_libraries
Seit 1.6.0 können Sie den Standardtyp der Bibliothek auswählen, der bei Verwendung eines both_libraries-Objekts ausgewählt wird. Dies kann entweder 'shared' (Standardwert, kompatibel mit früheren Meson-Versionen), 'static' oder 'auto' sein. Bei 'auto' wird der Wert der Option default_library verwendet, es sei denn, es ist 'both', in welchem Fall 'shared' stattdessen verwendet wird.
Wenn default_both_libraries auf 'auto' gesetzt ist, verknüpft die Übergabe einer both_libs-Abhängigkeit in both_libraries() die statische Abhängigkeit mit der statischen Lib und die dynamische Abhängigkeit mit der dynamischen Lib.
Basisoptionen
Diese werden auf die gleiche Weise wie universelle Optionen gesetzt, entweder durch -Doption=value oder durch Setzen in default_options von project() in Ihrer meson.build. Sie können jedoch nicht in der Ausgabe von meson setup --help angezeigt werden, da sie sowohl vom aktuellen Plattform als auch vom ausgewählten Compiler abhängen. Die einzige Möglichkeit, sie zu sehen, ist, ein Build-Verzeichnis einzurichten und dann meson configure darauf ohne Optionen auszuführen.
Die folgenden Optionen sind verfügbar. Beachten Sie, dass sie möglicherweise nicht auf allen Plattformen oder mit allen Compilern verfügbar sind
| Option | Standardwert | Mögliche Werte | Beschreibung |
|---|---|---|---|
| b_asneeded | true | true, false | Verwendet -Wl,--as-needed beim Linken |
| b_bitcode | false | true, false | Betten Sie Apple Bitcode ein, siehe unten |
| b_colorout | always | auto, always, never | Verwendet farbige Ausgabe |
| b_coverage | false | true, false | Aktiviert die Nachverfolgung der Abdeckung |
| b_lundef | true | true, false | Erlaubt keine undefinierten Symbole beim Linken |
| b_lto | false | true, false | Verwendet Link Time Optimization |
| b_lto_threads | 0 | Beliebige Ganzzahl* | Verwendet mehrere Threads für LTO. (Hinzugefügt in 0.57.0) |
| b_lto_mode | default | default, thin | Wählt zwischen LTO-Modi, thin und default. (Hinzugefügt in 0.57.0) |
| b_thinlto_cache | false | true, false | Aktiviert den ThinLTO-Cache von LLVM für schnellere inkrementelle Builds. (Hinzugefügt in 0.64.0) |
| b_thinlto_cache_dir | (Internes Build-Verzeichnis) | true, false | Gibt an, wo ThinLTO-Cache-Objekte gespeichert werden sollen. (Hinzugefügt in 0.64.0) |
| b_ndebug | false | true, false, if-release | Deaktiviert Assertions |
| b_pch | true | true, false | Verwendet vorkompilierte Header |
| b_pgo | off | off, generate, use | Verwendet profilgesteuerte Optimierung |
| b_sanitize | none | siehe unten | Zu verwendender Code-Sanitizer |
| b_staticpic | true | true, false | Erstellt statische Bibliotheken als positionunabhängig |
| b_pie | false | true, false | Erstellt positionunabhängige Executables (seit 0.49.0) |
| b_vscrt | from_buildtype | none, md, mdd, mt, mtd, from_buildtype, static_from_buildtype | Zu verwendende VS Runtime-Bibliothek (seit 0.48.0) (static_from_buildtype seit 0.56.0) |
Der Wert von b_sanitize kann einer der folgenden sein: none, address, thread, undefined, memory, leak, address,undefined, aber beachten Sie, dass einige Compiler möglicherweise nicht alle unterstützen. Zum Beispiel unterstützt Visual Studio nur den Adresssanitizer.
* < 0 bedeutet deaktivieren, == 0 bedeutet automatische Auswahl, > 0 legt eine bestimmte zu verwendende Nummer fest
LLVM unterstützt thin LTO. Weitere Informationen finden Sie in der Dokumentation von LLVM.
Der Standardwert von b_vscrt ist from_buildtype. Die folgende Tabelle wird intern verwendet, um die CRT-Compiler-Argumente für from_buildtype oder static_from_buildtype (seit 0.56) basierend auf dem Wert der Option buildtype auszuwählen
| buildtype | from_buildtype | static_from_buildtype |
|---|---|---|
| debug | /MDd
|
/MTd
|
| debugoptimized | /MD
|
/MT
|
| release | /MD
|
/MT
|
| minsize | /MD
|
/MT
|
| custom | error! | error! |
Hinweise zur Unterstützung von Apple Bitcode
b_bitcode übergibt -fembed-bitcode beim Kompilieren und -Wl,-bitcode_bundle beim Linken. Diese Optionen sind inkompatibel mit b_asneeded, daher wird diese Option stillschweigend deaktiviert.
shared_module()s werden keine Bitcodes eingebettet haben, da -Wl,-bitcode_bundle inkompatibel mit sowohl -bundle als auch -Wl,-undefined,dynamic_lookup ist, die für Shared Modules zur Funktion notwendig sind.
Compiler-Optionen
Gleiche Vorbehalte wie bei Basisoptionen oben.
Die folgenden Optionen sind verfügbar. Sie können gesetzt werden, indem -Doption=value an meson übergeben wird. Beachten Sie, dass sowohl die Optionen selbst als auch die möglichen Werte, die sie annehmen können, vom Zielplattform oder Compiler abhängen werden
| Option | Standardwert | Mögliche Werte | Beschreibung |
|---|---|---|---|
| c_args | Freiform-kommagetrennte Liste | Zu verwendende C-Kompilierungsargumente | |
| c_link_args | Freiform-kommagetrennte Liste | Zu verwendende C-Link-Argumente | |
| c_std | none | none, c89, c99, c11, c17, c18, c2x, c23, gnu89, gnu99, gnu11, gnu17, gnu18, gnu2x, gnu23 | Zu verwendender C-Sprachstandard |
| c_winlibs | siehe unten | Freiform-kommagetrennte Liste | Standard-Windows-Libs, gegen die gelinkt werden soll |
| c_thread_count | 4 | Ganzzahliger Wert ≥ 0 | Anzahl der Threads, die mit emcc bei Verwendung von Threads verwendet werden sollen |
| cpp_args | Freiform-kommagetrennte Liste | Zu verwendende C++-Kompilierungsargumente | |
| cpp_link_args | Freiform-kommagetrennte Liste | Zu verwendende C++-Link-Argumente | |
| cpp_std | none | none, c++98, c++03, c++11, c++14, c++17, c++20 c++2a, c++1z, gnu++03, gnu++11, gnu++14, gnu++17, gnu++1z, gnu++2a, gnu++20, vc++14, vc++17, vc++20, vc++latest |
Zu verwendender C++-Sprachstandard |
| cpp_debugstl | false | true, false | C++ STL-Debug-Modus |
| cpp_eh | default | none, default, a, s, sc | C++-Exception-Handling-Typ |
| cpp_rtti | true | true, false | Ob RTTI (Runtime Type Identification) aktiviert werden soll |
| cpp_thread_count | 4 | Ganzzahliger Wert ≥ 0 | Anzahl der Threads, die mit emcc bei Verwendung von Threads verwendet werden sollen |
| cpp_winlibs | siehe unten | Freiform-kommagetrennte Liste | Standard-Windows-Libs, gegen die gelinkt werden soll |
| fortran_std | none | [none, legacy, f95, f2003, f2008, f2018] | Zu verwendender Fortran-Sprachstandard |
| cuda_ccbindir | Dateisystempfad | CUDA nicht standardmäßiges Toolchain-Verzeichnis zu verwenden (-ccbin) (Hinzugefügt in 0.57.1) |
Die Standardwerte von c_winlibs und cpp_winlibs sind in compilerspezifischen Argumentformen, aber die Bibliotheken sind: kernel32, user32, gdi32, winspool, shell32, ole32, oleaut32, uuid, comdlg32, advapi32.
Alle diese <lang>_* Optionen werden pro Maschine angegeben. Sehen Sie unten im Abschnitt Optionen pro Maschine angeben, wie dies bei Cross-Builds geschieht.
Bei Verwendung von MSVC führt cpp_eh=[Wert] dazu, dass /EH[Wert] übergeben wird. Der magische Wert none wird zu s-c- übersetzt, um Exceptions zu deaktivieren. Seit 0.51.0 wird default zu sc übersetzt. Bei Verwendung von GCC-ähnlichen Compilern wird nichts übergeben (wodurch Exceptions funktionieren), während cpp_eh=none -fno-exceptions übergibt.
Seit 0.54.0 kann die Option <lang>_thread_count verwendet werden, um den Wert zu steuern, der an -s PTHREAD_POOL_SIZE übergeben wird, wenn emcc verwendet wird. Kein anderer C/C++-Compiler unterstützt diese Option.
Seit 0.63.0 können alle Compiler-Optionen pro Unterprojekt gesetzt werden. Weitere Details dazu, wie der Standardwert vom Hauptprojekt geerbt wird, finden Sie hier. Dies ist zum Beispiel nützlich, wenn das Hauptprojekt C++11 benötigt, ein Unterprojekt aber C++14 benötigt. Der cpp_std-Wert aus default_options des Unterprojekts wird nun berücksichtigt.
Seit 1.3.0 akzeptieren die Optionen c_std und cpp_std jetzt eine Liste von Werten. Projekte, die GNU C bevorzugen, aber auf ISO C zurückfallen können, können jetzt zum Beispiel default_options: 'c_std=gnu11,c11' setzen, und es wird gnu11 verwendet, wenn verfügbar, fällt aber auf c11 zurück. Es ist nur ein Fehler, wenn keiner der Werte vom aktuellen Compiler unterstützt wird. Ebenso kann ein Projekt, das von c++17 profitieren kann, aber immer noch mit c++11 erstellen kann, default_options: 'cpp_std=c++17,c++11' setzen. Dies ermöglicht es uns, gnuXX-Werte vom MSVC-Compiler zu verwerfen. Das bedeutet, dass default_options: 'c_std=gnu11' nun mit MSVC eine Warnung ausgibt, aber auf c11 zurückfällt. Es wird keine Warnung ausgegeben, wenn mindestens einer der Werte gültig ist, d.h. default_options: 'c_std=gnu11,c11'. In Zukunft wird diese Deprecations-Warnung zu einem harten Fehler, da c_std=gnu11 GNU erfordern sollte, zum Beispiel für Projekte, die nicht mit MSVC erstellt werden können.
Optionen pro Maschine angeben
Seit 0.51.0 werden einige Optionen pro Maschine und nicht global für alle Maschinenkonfigurationen angegeben. Das Präfixieren der Option mit build. beeinflusst nur die Build-Maschinenkonfiguration, während das Weglassen des Präfixes nur die Host-Maschinenkonfiguration beeinflusst. Zum Beispiel
-
build.pkg_config_pathsteuert die Pfade, die pkg-config fürnative: true(Build-Maschine) Abhängigkeiten durchsuchen wird. -
pkg_config_pathsteuert die Pfade, die pkg-config fürnative: false(Host-Maschine) Abhängigkeiten durchsuchen wird.
Dies ist nützlich für Cross-Builds. In nativen Builds sind die Build- und Host-Maschinen identisch, und die Option ohne Präfix allein ist ausreichend.
Vor 0.51.0 beeinflussten diese Optionen nur native Builds, wenn sie auf der Befehlszeile als es kein build. Präfix gab, angegeben wurden. Ähnlich benannte Felder im Abschnitt [properties] der Cross-Datei würden Cross-Compiler beeinflussen, aber die Code-Pfade waren ziemlich unterschiedlich, was zu Verhaltensunterschieden führte.
Optionen pro Unterprojekt angeben
Seit 0.54.0 können die eingebauten Optionen default_library und werror pro Unterprojekt definiert werden. Dies ist zum Beispiel nützlich, wenn im Hauptprojekt dynamische Bibliotheken erstellt werden und ein Unterprojekt statisch gelinkt wird, oder wenn das Hauptprojekt ohne Warnungen erstellt werden muss, einige Unterprojekte dies jedoch nicht können.
Meistens wird dies entweder im Elternprojekt durch Setzen der Standardoptionen des Unterprojekts (z. B. subproject('foo', default_options: 'default_library=static')) oder durch den Benutzer über die Befehlszeile: -Dfoo:default_library=static verwendet.
Der Wert wird in folgender Reihenfolge überschrieben
- Wert vom Elternprojekt
- Wert von default_options des Unterprojekts, falls gesetzt
- Wert von subproject() default_options, falls gesetzt
- Wert von der Befehlszeile, falls gesetzt
Seit 0.56.0 kann auch warning_level pro Unterprojekt definiert werden.
Moduloptionen
Einige Meson-Module haben eingebaute Optionen. Sie können gesetzt werden, indem die Option mit dem Namen des Moduls präfixiert wird: -D<modul>.<option>=<wert> (z.B. -Dpython.platlibdir=/foo).
Pkgconfig-Modul
| Option | Standardwert | Mögliche Werte | Beschreibung |
|---|---|---|---|
| relocatable | false | true, false | Generiert die pkgconfig-Dateien als relocatable (Seit 0.63.0) |
Seit 0.63.0 wird die Option pkgconfig.relocatable vom pkgconfig-Modul – nämlich pkg.generate() – verwendet und beeinflusst, wie das prefix (nicht zu verwechseln mit dem Installationspräfix) in der generierten pkgconfig-Datei gesetzt wird. Wenn es true ist, ist das prefix relativ zum install_dir – dies erlaubt es, die pkgconfig-Datei zu verschieben und sie trotzdem funktionsfähig zu halten, solange der relative Pfad nicht unterbrochen wird. Im Allgemeinen ermöglicht dies, dass das gesamte installierte Paket irgendwo im System platziert werden kann und trotzdem als Abhängigkeit funktioniert. Wenn es auf false gesetzt ist, ist das prefix dasselbe wie das Installationspräfix.
Es wird ein Fehler ausgelöst, wenn pkgconfig.relocatable auf true gesetzt ist und das install_dir für eine generierte pkgconfig-Datei außerhalb des Installationspräfixes liegt. Zum Beispiel: wenn das Installationspräfix /usr ist und das install_dir für eine pkgconfig-Datei /var/lib/pkgconfig ist.
Python-Modul
| Option | Standardwert | Mögliche Werte | Beschreibung |
|---|---|---|---|
| bytecompile | 0 | Ganzzahl von -1 bis 2 | Welche Bytecode-Optimierungsstufe verwendet werden soll (Seit 1.2.0) |
| install_env | prefix | {auto,prefix,system,venv} | In welche Python-Umgebung installiert werden soll (Seit 0.62.0) |
| platlibdir | Verzeichnispfad | Verzeichnis für standortspezifische, plattformspezifische Dateien (Seit 0.60.0) | |
| purelibdir | Verzeichnispfad | Verzeichnis für standortspezifische, nicht plattformspezifische Dateien (Seit 0.60.0) | |
| allow_limited_api | true | true, false | Deaktiviert die projektweite Verwendung der Python Limited API (Seit 1.3.0) |
Seit 0.60.0 werden die Optionen python.platlibdir und python.purelibdir von den Python-Modulmethoden python.install_sources() und python.get_install_dir() verwendet; Meson versucht, die korrekten Installationspfade zu erkennen und sie standardmäßig relativ zum Installationspräfix zu machen, was oft dazu führt, dass der Interpreter die installierten Python-Module nicht findet, es sei denn, das Präfix ist unter Linux /usr oder unter Windows z. B. C:\Python39. Diese Optionen können absolute Pfade außerhalb des Präfixes sein.
Seit 0.62.0 wird die Option python.install_env verwendet, um den korrekten Installationspfad zu erkennen. Die Einstellung auf system vermeidet, die Pfade relativ zum Präfix zu machen und verwendet stattdessen direkt die globalen Site-Packages des ausgewählten Python-Interpreters, auch wenn es sich um ein venv handelt. Die Einstellung auf venv verwendet stattdessen die Pfade für das virtuelle Environment, aus dem die gefundene Python-Installation stammt (oder schlägt fehl, wenn es sich nicht um ein virtuelles Environment handelt). Die Einstellung auf auto prüft, ob die gefundene Installation ein virtuelles Environment ist, und verwendet entsprechend venv oder system (aber niemals prefix). Beachten Sie, dass Conda-Umgebungen als system behandelt werden. Diese Option ist mit platlibdir/purelibdir nicht kompatibel.
Aus Gründen der Abwärtskompatibilität ist der Standardwert für install_env prefix.
Seit 1.2.0 kann die Option python.bytecompile verwendet werden, um das Kompilieren von Python-Bytecode zu aktivieren. Bytecode hat 3 Optimierungsstufen
- 0, Bytecode ohne Optimierungen
- 1, Bytecode mit einigen Optimierungen
- 2, Bytecode mit weiteren Optimierungen
Zusätzlich fügt Meson die Stufe -1 hinzu, was bedeutet, dass keine Bytecode-Kompilierung versucht wird.
Seit 1.3.0 die Option python.allow_limited_api beeinflusst, ob das Schlüsselwortargument limited_api der Methode extension_module beachtet wird. Wenn es auf false gesetzt ist, wird die Auswirkung des Arguments limited_api deaktiviert.
Die Ergebnisse der Suche sind