Emscripten Compiler-Einstellungen

Im Folgenden finden Sie eine vollständige Liste der Einstellungen, die Emscripten über -s in der Befehlszeile übergeben werden können. Zum Beispiel -sASSERTIONS oder -sASSERTIONS=0. Weitere Details finden Sie in der emcc-Dokumentation.

Sofern nicht anders vermerkt, gelten diese Einstellungen nur beim Linken und haben keine Auswirkung während der Kompilierung.

ASSERTIONS

Ob wir Laufzeit-Assertions hinzufügen sollen. Dies beeinflusst sowohl JS als auch die Art und Weise, wie Systembibliotheken erstellt werden. ASSERTIONS == 2 bietet noch mehr Laufzeitprüfungen, die sehr langsam sein können. Dazu gehören beispielsweise interne dlmalloc-Assertions.

Standardwert: 1

STACK_OVERFLOW_CHECK

Wählt aus, welche Art von Stack-Smash-Prüfungen in den generierten Code ausgegeben werden sollen: Das Erstellen mit ASSERTIONS=1 führt dazu, dass STACK_OVERFLOW_CHECK standardmäßig auf 1 gesetzt wird. Da ASSERTIONS=1 der Standard bei -O0 ist, was wiederum die Standardoptimierungsstufe ist, bedeutet dies, dass diese Einstellung effektiv auch standardmäßig 1 ist, sofern keine anderen Einstellungen vorhanden sind.

• 0: Stack-Überläufe werden nicht überprüft.

• 1: Fügt ein Sicherheitscookie am oberen Ende des Stacks hinzu, das am Ende jedes Ticks und beim Beenden überprüft wird (praktisch kein Performance-Overhead).

• 2: Wie oben, aber führt auch einen Binaryen-Pass aus, der eine Prüfung zu allen Stack-Pointer-Zuweisungen hinzufügt. Hat einen geringen Performance-Kosten.

Standardwert: 0

CHECK_NULL_WRITES

Wenn STACK_OVERFLOW_CHECK aktiviert ist, überprüfen wir auch Schreibvorgänge an die Adresse Null. Dies kann helfen, die Verwendung von NULL-Zeigern zu erkennen. Wenn Sie diese zusätzliche Prüfung überspringen möchten (z. B. wenn Sie möchten, dass Lesevorgänge von der Adresse Null immer Null zurückgeben), können Sie dies hier deaktivieren. Diese Einstellung hat keine Auswirkung, wenn STACK_OVERFLOW_CHECK deaktiviert ist.

Standardwert: true

VERBOSE

Wenn auf 1 gesetzt, wird während der Kompilierung eine ausführlichere Ausgabe generiert. [general]

Standardwert: false

INVOKE_RUN

Ob wir die Funktion main() ausführen werden. Deaktivieren Sie dies, wenn Sie den generierten Code in Ihren eigenen Code einbetten und main() selbst zur richtigen Zeit aufrufen werden (was Sie mit Module.callMain() tun können, mit einem optionalen Parameter für Befehlszeilenargumente).

Standardwert: true

EXIT_RUNTIME

Wenn 0, wird die Laufzeit nicht beendet, wenn main() abgeschlossen ist (was es ermöglicht, dass Code danach ausgeführt wird, z. B. aus der Haupt-Ereignisschleife des Browsers). atexit()s werden ebenfalls nicht ausgeführt, und wir können vermeiden, Code für die Laufzeitbeendigung, wie das Leeren der stdio-Streams, einzuschließen. Setzen Sie dies auf 1, wenn Sie atexit()s oder stdio-Streams beim Beenden geleert haben möchten. Diese Einstellung wird im STANDALONE_WASM-Modus automatisch gesteuert.

• Für einen Befehl (hat eine main-Funktion) ist dies immer 1.

• Für einen Reaktor (keine main-Funktion) ist dies immer 0.

Standardwert: false

STACK_SIZE

Die Gesamtstackgröße. Es gibt keine Möglichkeit, den Stack zu vergrößern, daher muss dieser Wert groß genug für die Anforderungen des Programms sein. Wenn Assertions eingeschaltet sind, wird eine Assertion ausgelöst, wenn dieser Wert überschritten wird, andernfalls schlägt er stillschweigend fehl.

Standardwert: 64*1024

MALLOC

Welches malloc()/free() zu verwenden ist, aus:

• dlmalloc - ein leistungsstarkes Allzweck-malloc

• emmalloc - ein einfaches und kompaktes malloc, das für emscripten entwickelt wurde

• emmalloc-debug - verwendet emmalloc und fügt zusätzliche Assertionsprüfungen hinzu

• emmalloc-memvalidate - verwendet emmalloc mit Assertions + Heap-Konsistenzprüfung.

• emmalloc-verbose - verwendet emmalloc mit Assertions + ausführlicher Protokollierung.

• emmalloc-memvalidate-verbose - verwendet emmalloc mit Assertions + Heap-Konsistenzprüfung + ausführlicher Protokollierung.

• mimalloc - ein leistungsstarker Multithread-Allocator. Dieser wird in großen Anwendungen mit malloc()-Konflikten empfohlen, ist aber größer und verbraucht mehr Speicher.

• none - es wird keine malloc()-Implementierung bereitgestellt, Sie müssen malloc() und free() jedoch selbst implementieren.

dlmalloc ist für geteilten Speicher und andere spezielle Modi erforderlich und wird in diesen Fällen automatisch verwendet. Im Allgemeinen sollten Sie emmalloc verwenden, wenn Sie keinen dieser speziellen Modi benötigen und nicht sehr viele kleine Objekte zuweisen, da es kleiner ist. Andernfalls, wenn Sie viele kleine Objekte zuweisen, ist dlmalloc den zusätzlichen Speicherplatz meist wert. dlmalloc ist auch eine gute Wahl, wenn Sie die zusätzlichen Sicherheitsprüfungen wünschen, die es durchführt (z. B. das Erkennen von Metadatenkorruption in seinen internen Datenstrukturen, was emmalloc nicht tut).

Standardwert: "dlmalloc"

ABORTING_MALLOC

Wenn 1, dann abort() wenn malloc fehlschlagen würde. Dies ist ein nicht standardmäßiges Verhalten, ist aber für das Web sinnvoll, da wir eine feste Speichermenge haben, die alle im Voraus zugewiesen werden muss, und daher (a) fehlschlagende mallocs viel wahrscheinlicher sind als auf anderen Plattformen, und (b) Benutzer eine Möglichkeit benötigen, herauszufinden, wie groß diese anfängliche Zuweisung (INITIAL_MEMORY) sein muss. Wenn Sie dies auf 0 setzen, erhalten Sie das Standard-malloc-Verhalten, bei dem im Fehlerfall NULL (0) zurückgegeben wird.

Die Einstellung ALLOW_MEMORY_GROWTH schaltet dies aus, da wir in diesem Modus standardmäßig das Verhalten anwenden, zu versuchen, den Speicher zu vergrößern und im Fehlerfall 0 von malloc zurückzugeben, wie es ein Standardsystem tun würde. Sie können dieses Flag jedoch weiterhin setzen, um dies zu überschreiben. Dies ist eine größtenteils rückwärtskompatible Änderung. Zuvor wurde diese Option ignoriert, wenn das Wachstum aktiviert war. Das aktuelle Verhalten ist, dass Wachstum es standardmäßig ausschaltet, sodass sich für Benutzer, die das Flag nie angegeben haben, nichts ändert. Aber wenn Sie es angeben, wird es jetzt eine Wirkung haben, was es vorher nicht tat. Wenn Sie das nicht möchten, hören Sie einfach auf, es zur Linkzeit zu übergeben.

Beachten Sie, dass diese Einstellung das Verhalten des Operators new in C++ nicht beeinflusst. Diese Funktion bricht immer bei Zuweisungsfehlern ab, wenn Ausnahmen deaktiviert sind. Wenn Sie möchten, dass new bei einem Fehler 0 zurückgibt, verwenden Sie es mit std::nothrow.

Standardwert: true

INITIAL_HEAP

Die anfängliche Heap-Speichermenge, die dem Programm zur Verfügung steht. Dies ist der Speicherbereich, der für dynamische Zuweisungen über sbrk, malloc und new verfügbar ist.

Im Gegensatz zu INITIAL_MEMORY ermöglicht diese Einstellung, dass die statischen und dynamischen Bereiche des Programmspeichers unabhängig voneinander wachsen. In den meisten Fällen empfehlen wir die Verwendung dieser Einstellung anstelle von INITIAL_MEMORY. Diese Einstellung funktioniert jedoch nicht für importierte Speicher (z.B. wenn dynamisches Linking verwendet wird).

Standardwert: 16777216

INITIAL_MEMORY

Die anfänglich zu verwendende Speichermenge. Die Verwendung von mehr Speicher als diesem führt dazu, dass wir den Heap erweitern, was bei typisierten Arrays kostspielig sein kann: In diesem Fall müssen wir den alten Heap in einen neuen kopieren. Wenn ALLOW_MEMORY_GROWTH gesetzt ist, kann diese anfängliche Speichermenge später erhöht werden; wenn nicht, dann ist es die endgültige und gesamte Speichermenge.

Standardmäßig wird dieser Wert basierend auf INITIAL_HEAP, STACK_SIZE sowie der Größe statischer Daten in Eingabemodulen berechnet.

(Diese Option wurde früher TOTAL_MEMORY genannt.)

Standardwert: -1

MAXIMUM_MEMORY

Setzt die maximale Größe des Speichers im wasm-Modul (in Bytes). Dies ist nur relevant, wenn ALLOW_MEMORY_GROWTH gesetzt ist, da ohne Wachstum die Größe von INITIAL_MEMORY ohnehin die endgültige Speichergröße ist.

Beachten Sie, dass der Standardwert hier 2 GB beträgt, was bedeutet, dass wir standardmäßig, wenn Sie das Speicherwachstum aktivieren, bis zu 2 GB wachsen können, aber nicht höher. 2 GB ist aus mehreren Gründen eine natürliche Grenze:

• Wenn die maximale Heap-Größe über 2 GB liegt, müssen Zeiger in JavaScript vorzeichenlos sein, was die Code-Größe erhöht. Wir möchten nicht, dass Builds mit Speicherwachstum größer sind, es sei denn, jemand entscheidet sich explizit für Heaps >2 GB+.

• Historisch hat keine VM mehr als 2 GB+ unterstützt, und erst kürzlich (März 2020) begann die Unterstützung aufzutauchen. Da die Unterstützung begrenzt ist, ist es für Benutzer sicherer, sich für Heaps >2 GB+ zu entscheiden, anstatt einen Build zu erhalten, der möglicherweise nicht auf allen VMs funktioniert.

Um mehr als 2 GB zu verwenden, setzen Sie diesen Wert höher, z. B. 4 GB.

(Diese Option wurde früher WASM_MEM_MAX und BINARYEN_MEM_MAX genannt.)

Standardwert: 2147483648

ALLOW_MEMORY_GROWTH

Wenn false, brechen wir mit einem Fehler ab, wenn wir versuchen, mehr Speicher zu allozieren, als wir können (INITIAL_MEMORY). Wenn true, erweitern wir die Speicherarrays zur Laufzeit, nahtlos und dynamisch. Siehe https://code.google.com/p/v8/issues/detail?id=3907 bezüglich der Speicherwachstumsleistung in Chrome. Beachten Sie, dass das Erweitern des Speichers bedeutet, dass wir die JS-Typ-Array-Views ersetzen, da sie einmal erstellt nicht in der Größe geändert werden können. (In wasm können wir den Speicher erweitern, müssen aber immer noch neue Views für JS erstellen.) Wenn diese Option aktiviert ist, wird ABORTING_MALLOC deaktiviert, d.h. ALLOW_MEMORY_GROWTH ermöglicht ein vollständig standardmäßiges Verhalten, sowohl dass malloc 0 zurückgibt, wenn es fehlschlägt, als auch dass bei Bedarf mehr Speicher vom System zugewiesen werden kann.

Standardwert: false

MEMORY_GROWTH_GEOMETRIC_STEP

Wenn ALLOW_MEMORY_GROWTH wahr ist, spezifiziert diese Variable die geometrische Überwachstumsrate des Heaps bei der Größenänderung. Setzen Sie MEMORY_GROWTH_GEOMETRIC_STEP=0, um das Überwachsen des Heaps vollständig zu deaktivieren, oder z.B. MEMORY_GROWTH_GEOMETRIC_STEP=1.0, um den Heap bei jedem Wachstumsschritt zu verdoppeln (+100%). Je größer dieser Wert ist, desto mehr Speicher reserviert der WebAssembly-Heap über, um Performance-Einbrüche durch Speichergrößenänderungen zu reduzieren, und je kleiner dieser Wert ist, desto mehr Speicher wird gespart, auf Kosten von mehr Rucklern beim Wachsen des Heaps. (profiliert auf ca. ~20 ms)

Standardwert: 0.20

MEMORY_GROWTH_GEOMETRIC_CAP

Spezifiziert eine Obergrenze für die maximale geometrische Überwachstumsgröße in Bytes. Verwenden Sie diesen Wert, um das geometrische Wachstum so zu begrenzen, dass eine bestimmte Rate nicht überschritten wird. Übergeben Sie MEMORY_GROWTH_GEOMETRIC_CAP=0, um die Begrenzung zu deaktivieren und unbegrenzte Größensteigerungen zuzulassen.

Standardwert: 96*1024*1024

MEMORY_GROWTH_LINEAR_STEP

Wenn ALLOW_MEMORY_GROWTH wahr und MEMORY_GROWTH_LINEAR_STEP == -1 ist, wird geometrisches Speicherüberwachstum verwendet (obige Variable). Setzen Sie MEMORY_GROWTH_LINEAR_STEP auf ein Vielfaches der WASM-Seitengröße (64KB), z.B. 16MB, um die geometrische Überwachstumsrate durch eine konstante Wachstumsschrittgröße zu ersetzen. Wenn MEMORY_GROWTH_LINEAR_STEP verwendet wird, werden die Variablen MEMORY_GROWTH_GEOMETRIC_STEP und MEMORY_GROWTH_GEOMETRIC_CAP ignoriert.

Standardwert: -1

MEMORY64

Die „Architektur“, für die kompiliert werden soll. 0 bedeutet das standardmäßige wasm32, 1 ist der vollständige End-to-End-wasm64-Modus und 2 ist wasm64 für clang/lld, aber in Binaryen auf wasm32 herabgestuft (so dass es auf wasm32-Engines laufen kann, während intern i64-Zeiger verwendet werden). Setzt WASM_BIGINT voraus.

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Hinweis

Dies ist eine experimentelle Einstellung

Standardwert: 0

INITIAL_TABLE

Setzt die anfängliche Größe der Tabelle, wenn MAIN_MODULE oder SIDE_MODULE verwendet wird (und sonst nicht). Normalerweise kann Emscripten die Größe der Tabelle zur Linkzeit bestimmen, aber im SPLIT_MODULE-Modus muss wasm-split die Tabelle oft vergrößern, so dass die in das JS für den instrumentierten Build eingebackene Tabellengröße nach dem Teilen des Moduls zu klein ist. Dies ist ein Hack, um Benutzern zu ermöglichen, eine ausreichend große Tabellengröße anzugeben, die über beide Builds hinweg konsistent sein kann. Diese Einstellung kann jederzeit entfernt werden und sollte nur in Verbindung mit SPLIT_MODULE und dynamischem Linking verwendet werden.

Standardwert: -1

ALLOW_TABLE_GROWTH

Wenn true, erlaubt dies das Hinzufügen weiterer Funktionen zur Tabelle zur Laufzeit. Dies ist für das dynamische Linken notwendig und wird in diesem Modus automatisch gesetzt.

Standardwert: false

GLOBAL_BASE

Wo globale Daten beginnen; der Start des statischen Speichers. Ein GLOBAL_BASE von 1024 oder höher ist nützlich zur Optimierung von Lade-/Speicher-Offsets, da es den --low-memory-unused Pass aktiviert.

Standardwert: 1024

TABLE_BASE

Wo Tabellenslots (Funktionsadressen) zugewiesen werden. Dies muss mindestens 1 sein, um den Null-Slot für den Nullzeiger zu reservieren.

Standardwert: 1

USE_CLOSURE_COMPILER

Ob die Closure-Kompilierung für diese Ausgabe ausgeführt wird

Standardwert: false

CLOSURE_WARNINGS

Veraltet: Verwenden Sie stattdessen die Standard-Warnflags. z.B. -Wclosure, -Wno-closure, -Werror=closure. Optionen: 'quiet', 'warn', 'error'. Wenn auf 'warn' gesetzt, werden Closure-Warnungen in der Konsole ausgegeben. Wenn auf 'error' gesetzt, werden Closure-Warnungen wie Fehler behandelt, ähnlich dem Compiler-Flag -Werror.

Hinweis

Diese Einstellung ist veraltet

Standardwert: 'quiet'

IGNORE_CLOSURE_COMPILER_ERRORS

Ignoriere Closure-Warnungen und -Fehler (z.B. bei doppelten Definitionen)

Standardwert: false

DECLARE_ASM_MODULE_EXPORTS

Wenn auf 1 gesetzt, wird jeder wasm-Modulexport individuell mit einer JavaScript-"var"-Definition deklariert. Dies ist der einfache und empfohlene Ansatz. Dies erhöht jedoch die Code-Größe (insbesondere bei vielen solchen Exporten), was auf unsichere Weise vermieden werden kann, indem dieser Wert auf 0 gesetzt wird. In diesem Fall wird keine "var" für jeden Export erstellt, stattdessen schreibt eine Schleife (mit kleiner konstanter Code-Größe, unabhängig von der Anzahl der Exporte) alle empfangenen Exporte in den globalen Bereich. Dies ist gefährlich, da solche Änderungen des globalen Bereichs externe JS-Minifier-Tools verwirren können, und auch Dinge kaputtgehen können, wenn der Bereich, in dem sich der Code befindet, nicht der globale Bereich ist (z.B. wenn Sie sie manuell in einen Funktionsbereich einschließen).

Standardwert: true

INLINING_LIMIT

Wenn auf 1 gesetzt, wird das Inlining verhindert. Wenn 0, führen wir das Inlining in LLVM normal durch. Dies beeinflusst die Inlining-Richtlinie in Binaryen nicht.

Hinweis

Nur während der Kompilierung anwendbar

Standardwert: false

SUPPORT_BIG_ENDIAN

Wenn auf 1 gesetzt, führt einen Acorn-Pass durch, der jeden HEAP-Zugriff in einen Funktionsaufruf umwandelt, der DataView verwendet, um die LE-Byte-Reihenfolge für den HEAP-Puffer zu erzwingen; dies bewirkt, dass der generierte JavaScript-Code sowohl auf BE- als auch auf LE-Maschinen läuft. (Wenn 0, werden nur LE-Systeme unterstützt). Hat keinen Einfluss auf das generierte wasm.

Standardwert: false

SAFE_HEAP

Jeder Schreibvorgang auf den Heap wird überprüft, dies führt z.B. zu einem eindeutigen Fehler bei dem, was in einem nativen Build Segmentierungsfehler (wie Dereferenzierung von 0) wären. Siehe runtime_safe_heap.js für die tatsächlich durchgeführten Prüfungen. Setzen Sie den Wert auf 1, um sicheres Verhalten für Wasm+Wasm2JS-Builds zu testen. Setzen Sie den Wert auf 2, um sicheres Verhalten nur für Wasm-Builds zu testen. (Insbesondere erlauben Wasm-only-Builds nicht-ausgerichtete Speicherzugriffe. Beachten Sie jedoch, dass auf einigen Architekturen nicht-ausgerichtete Zugriffe sehr langsam sein können, daher ist es immer noch eine gute Idee, Ihren Code mit dem strengeren Modus 1 zu überprüfen.)

Standardwert: 0

SAFE_HEAP_LOG

Protokolliert alle SAFE_HEAP-Operationen

Standardwert: false

EMULATE_FUNCTION_POINTER_CASTS

Erlaubt die Umwandlung von Funktionszeigern, umwickelt jeden Aufruf eines falschen Typs mit einer Laufzeitkorrektur. Dies fügt Overhead hinzu und sollte normalerweise nicht verwendet werden. Abgesehen davon, dass Aufrufe nicht fehlschlagen, versucht dies, Werte bestmöglich zu konvertieren. Wir verwenden 64 Bit (i64), um Werte darzustellen, als ob wir den gesendeten Wert in den Speicher geschrieben und den empfangenen Typ aus demselben Speicher geladen hätten (mithilfe von truncs/extends/reinterprets). Dies bedeutet, dass bei nicht übereinstimmenden Typen die emulierten Werte möglicherweise nicht übereinstimmen (dies gilt übrigens auch für nativ – dies ist alles undefiniertes Verhalten). Dieser Ansatz scheint gut genug zu sein, um Python zu unterstützen, was der Hauptanwendungsfall für diese Funktion ist.

Standardwert: false

EXCEPTION_DEBUG

Gibt Ausnahmen in Emscripten-Code aus.

Standardwert: false

DEMANGLE_SUPPORT

Wenn 1, exportiert die JS-Bibliotheksfunktionen demangle und stackTrace.

Hinweis

Diese Einstellung ist veraltet

Standardwert: false

LIBRARY_DEBUG

Gibt aus, wann wir einen Bibliotheksaufruf (library*.js) betreten. Sie können auch runtimeDebug zur Laufzeit deaktivieren, um die Protokollierung zu beenden, und es wieder aktivieren, wenn Sie es benötigen. Eine einfache Möglichkeit, es in C++ festzulegen, ist:

emscripten_run_script("runtimeDebug = ...;");

Standardwert: false

SYSCALL_DEBUG

Gibt alle musl-Systemaufrufe aus, einschließlich der Übersetzung ihres numerischen Index in den String-Namen, was für die Fehlersuche praktisch sein kann. (Andere Systemaufrufe sind nicht nummeriert und haben bereits klare Namen; verwenden Sie LIBRARY_DEBUG, um die Protokollierung für alle zu erhalten.)

Standardwert: false

SOCKET_DEBUG

Protokolliert Socket-/Netzwerkdatenübertragung.

Standardwert: false

DYLINK_DEBUG

Protokollinformationen des dynamischen Linkers

Standardwert: 0

FS_DEBUG

Registriert Dateisystem-Callbacks mit trackingDelegate in library_fs.js

Standardwert: false

SOCKET_WEBRTC

Die Einstellungen WEBSOCKET_URL und WEBSOCKET_SUBPROTOCOL können nicht nur zur Kompilierzeit über die Option "-s" konfiguriert werden, sondern auch zur Laufzeit über das Module-Objekt, z.B. Module['websocket'] = {subprotocol: 'base64, binary, text'}; Module['websocket'] = {url: 'wss://', subprotocol: 'base64'}; Sie können 'subprotocol' auf null setzen, wenn Sie es nicht angeben möchten. Die Laufzeitkonfiguration kann nützlich sein, da sie einer Anwendung die Auswahl mehrerer verschiedener Dienste ermöglicht.

Standardwert: false

WEBSOCKET_URL

Ein String, der entweder ein WebSocket-URL-Präfix (ws:// oder wss://) oder eine vollständige RFC 6455-URL enthält – "ws[s]:" "//" host [ ":" port ] path [ "?" query ]. Im (Standard-)Fall, dass nur ein Präfix angegeben wird, wird die URL aus prefix + addr + ':' + port konstruiert, wobei addr und port von den Socket-Connect-/Bind-/Accept-Aufrufen abgeleitet werden.

Standardwert: 'ws://'

PROXY_POSIX_SOCKETS

Wenn 1, verwendet die POSIX-Sockets-API einen nativen Bridge-Prozessserver, um Socket-Aufrufe vom Browser zur nativen Welt zu proxen.

Standardwert: false

WEBSOCKET_SUBPROTOCOL

Ein String, der eine durch Kommas getrennte Liste von WebSocket-Subprotokollen enthält, wie sie im Sec-WebSocket-Protocol-Header vorhanden wären. Sie können 'null' setzen, wenn Sie es nicht angeben möchten.

Standardwert: 'binary'

OPENAL_DEBUG

Gibt Debugging-Informationen aus unserer OpenAL-Implementierung aus.

Standardwert: false

WEBSOCKET_DEBUG

Wenn 1, werden Debugging-Informationen bezüglich der Aufrufe von emscripten_web_socket_*-Funktionen in emscripten/websocket.h ausgegeben. Wenn 2, werden zusätzlich die über die Sockets kommunizierten Bytes nachverfolgt.

Standardwert: false

GL_ASSERTIONS

Fügt zusätzliche Prüfungen für Fehlersituationen in der GL-Bibliothek hinzu. Kann die Leistung beeinträchtigen.

Standardwert: false

TRACE_WEBGL_CALLS

Wenn aktiviert, werden alle API-Aufrufe an WebGL-Kontexte ausgegeben. (sehr ausführlich)

Standardwert: false

GL_DEBUG

Aktiviert eine ausführlichere Debug-Ausgabe von WebGL-bezogenen Operationen. Wie bei LIBRARY_DEBUG kann dies zur Laufzeit mit der Option GL.debug umgeschaltet werden.

Standardwert: false

GL_TESTING

Wenn aktiviert, wird preserveDrawingBuffer im Kontext gesetzt, um Tests zu ermöglichen (fügt jedoch Overhead hinzu)

Standardwert: false

GL_MAX_TEMP_BUFFER_SIZE

Wie groß GL-Emulations-Zwischenspeicher sind

Standardwert: 2097152

GL_UNSAFE_OPTS

Aktiviert einige potenziell unsichere Optimierungen im GL-Emulationscode

Standardwert: true

FULL_ES2

Erzwingt die Unterstützung aller GLES2-Funktionen, nicht nur der WebGL-freundlichen Untergruppe.

Standardwert: false

GL_EMULATE_GLES_VERSION_STRING_FORMAT

Wenn true, geben glGetString() für GL_VERSION und GL_SHADING_LANGUAGE_VERSION Strings im OpenGL ES-Format "Open GL ES ... (WebGL ...)" zurück, anstatt des WebGL-Formats. Wenn false, werden die direkten WebGL-Format-Strings zurückgegeben. Setzen Sie dies auf true, damit GL-Kontexte in diesen Versions-Strings wie ein OpenGL ES-Kontext erscheinen (auf Kosten einer kleinen zusätzlichen Code-Größe), und auf false, damit GL-Kontexte wie WebGL-Kontexte erscheinen und einige Bytes aus der Ausgabe gespart werden.

Standardwert: true

GL_EXTENSIONS_IN_PREFIXED_FORMAT

Wenn true, werden alle GL-Erweiterungen sowohl im nicht-präfixierten WebGL-Erweiterungsformat als auch im Desktop-/Mobil-GLES/GL-Erweiterungsformat mit GL_-Präfix beworben.

Standardwert: true

GL_SUPPORT_AUTOMATIC_ENABLE_EXTENSIONS

Wenn true, wird die Unterstützung für das automatische Aktivieren aller GL-Erweiterungen für GLES/GL-Emulationszwecke hinzugefügt. Dies beansprucht Code-Größe. Wenn Sie dies auf 0 setzen, müssen Sie die benötigten Erweiterungen manuell aktivieren.

Standardwert: true

GL_SUPPORT_SIMPLE_ENABLE_EXTENSIONS

Wenn true, kann die Funktion emscripten_webgl_enable_extension() aufgerufen werden, um jede WebGL-Erweiterung zu aktivieren. Wenn false, um Code-Größe zu sparen, kann emscripten_webgl_enable_extension() nicht aufgerufen werden, um die Erweiterungen 'ANGLE_instanced_arrays', 'OES_vertex_array_object', 'WEBGL_draw_buffers', 'WEBGL_multi_draw', 'WEBGL_draw_instanced_base_vertex_base_instance' oder 'WEBGL_multi_draw_instanced_base_vertex_base_instance' zu aktivieren, stattdessen werden die dedizierten Funktionen emscripten_webgl_enable_*() aus html5.h verwendet, um jede dieser Erweiterungen zu aktivieren. Auf diese Weise wird die Code-Größe nur für die tatsächlich verwendeten Erweiterungen erhöht. N.B. wenn dies auf 0 gesetzt wird, muss GL_SUPPORT_AUTOMATIC_ENABLE_EXTENSIONS ebenfalls auf Null gesetzt werden.

Standardwert: true

GL_TRACK_ERRORS

Wenn auf 0 gesetzt, verfolgt die Emscripten GLES2->WebGL-Übersetzungsschicht nicht die Art von GL-Fehlern, die in GLES2 existieren, aber nicht in WebGL. Das Setzen auf 0 spart Code-Größe. (Gut für die Entwicklung auf 1 zu halten)

Standardwert: true

GL_SUPPORT_EXPLICIT_SWAP_CONTROL

Wenn true, unterstützen GL-Kontexte das Kontext-Erstellungs-Flag explicitSwapControl. Setzen Sie auf 0, um ein wenig Platz bei Projekten zu sparen, die es nicht benötigen.

Standardwert: false

GL_POOL_TEMP_BUFFERS

Wenn wahr, verwenden Aufrufe von glUniform*fv und glUniformMatrix*fv einen Pool von vorallokierten temporären Puffern für gängige kleine Größen, um die Erzeugung von temporärem Müll für WebGL 1 zu vermeiden. Deaktivieren Sie dies, um die generierte Größe der GL-Bibliothek ein wenig zu optimieren, auf Kosten der Erzeugung von Müll in WebGL 1. Wenn Sie nur WebGL 2 verwenden und WebGL 1 nicht unterstützen, ist dies nicht erforderlich und Sie können es deaktivieren.

Standardwert: true

GL_EXPLICIT_UNIFORM_LOCATION

Wenn true, aktiviert die Unterstützung für die EMSCRIPTEN_explicit_uniform_location WebGL-Erweiterung. Siehe docs/EMSCRIPTEN_explicit_uniform_location.txt

Standardwert: false

GL_EXPLICIT_UNIFORM_BINDING

Wenn true, aktiviert die Unterstützung für die EMSCRIPTEN_uniform_layout_binding WebGL-Erweiterung. Siehe docs/EMSCRIPTEN_explicit_uniform_binding.txt

Standardwert: false

USE_WEBGL2

Veraltet. Übergeben Sie -sMAX_WEBGL_VERSION=2, um auf WebGL 2.0 abzuzielen.

Standardwert: false

MIN_WEBGL_VERSION

Gibt die niedrigste WebGL-Version an, auf die abzuzielen ist. Übergeben Sie -sMIN_WEBGL_VERSION=1, um WebGL 1 zu aktivieren, und -sMIN_WEBGL_VERSION=2, um die Unterstützung für WebGL 1.0 zu deaktivieren.

Standardwert: 1

MAX_WEBGL_VERSION

Spezifiziert die höchste WebGL-Version, auf die abzuzielen ist. Übergeben Sie -sMAX_WEBGL_VERSION=2, um WebGL 2 zu aktivieren. Wenn WebGL 2 aktiviert ist, erstellen einige APIs (EGL, GLUT, SDL) standardmäßig einen WebGL 2-Kontext, wenn keine Version angegeben ist. Beachten Sie, dass es keinen automatischen Fallback auf WebGL1 gibt, wenn WebGL2 vom Gerät des Benutzers nicht unterstützt wird, selbst wenn Sie mit sowohl WebGL1- als auch WebGL2-Unterstützung bauen, da dies möglicherweise nicht immer dem Wunsch der Anwendung entspricht. Wenn Sie einen solchen Fallback wünschen, können Sie versuchen, einen Kontext mit WebGL2 zu erstellen, und wenn dies fehlschlägt, versuchen Sie, einen mit WebGL1 zu erstellen.

Standardwert: 1

WEBGL2_BACKWARDS_COMPATIBILITY_EMULATION

Wenn true, emuliert einige WebGL 1-Funktionen auf WebGL 2-Kontexten, was bedeutet, dass Anwendungen, die WebGL 1/GLES 2 verwenden, einen WebGL 2/GLES3-Kontext initialisieren können, aber weiterhin WebGL1/GLES 2-Funktionalität verwenden, die in WebGL2/GLES3 nicht mehr unterstützt wird. Derzeit emuliert dies die Erweiterung GL_EXT_shader_texture_lod in GLSLES 1.00-Shadern, die Unterstützung für unbestimmte interne Texturformate und die Verwechslung von GL_HALF_FLOAT_OES != GL_HALF_FLOAT.

Standardwert: false

FULL_ES3

Erzwingt die Unterstützung aller GLES3-Funktionen, nicht nur der WebGL2-freundlichen Untergruppe. Dies schaltet automatisch FULL_ES2 und WebGL2-Unterstützung ein.

Standardwert: false

LEGACY_GL_EMULATION

Enthält Code zur Emulation verschiedener Desktop-GL-Funktionen. Unvollständig, aber in einigen Fällen nützlich, siehe http://kripken.github.io/emscripten-site/docs/porting/multimedia_and_graphics/OpenGL-support.html

Standardwert: false

GL_FFP_ONLY

Wenn Sie LEGACY_GL_EMULATION = 1 angegeben und in Ihrem Code nur die Fixed Function Pipeline verwenden, können Sie dies auch auf 1 setzen, um die GL-Emulationsschicht darauf hinzuweisen, dass sie zusätzliche Optimierungen durchführen kann, indem sie weiß, dass der Benutzercode überhaupt keine Shader verwendet. Wenn LEGACY_GL_EMULATION = 0, hat diese Einstellung keine Auswirkung.

Standardwert: false

GL_PREINITIALIZED_CONTEXT

Wenn Sie den WebGL-Kontext im JS-Code im Voraus erstellen möchten, setzen Sie dies auf 1 und setzen Sie Module['preinitializedWebGLContext'] auf einen vorab erstellten WebGL-Kontext. Die WebGL-Initialisierung danach wird diesen GL-Kontext zum Rendern verwenden.

Standardwert: false

USE_WEBGPU

Aktiviert die Unterstützung für WebGPU (über "webgpu/webgpu.h").

Standardwert: false

STB_IMAGE

Aktiviert das Erstellen von stb-image, einer winzigen Public-Domain-Bibliothek zum Decodieren von Bildern, die das Decodieren von Bildern ohne Verwendung der integrierten Decoder des Browsers ermöglicht. Der Vorteil ist, dass dies synchron erfolgen kann, jedoch nicht so schnell wie der Browser selbst ist. Wenn aktiviert, wird stb-image automatisch von IMG_Load und IMG_Load_RW verwendet. Sie können die stbi_*-Funktionen auch direkt selbst aufrufen.

Standardwert: false

GL_DISABLE_HALF_FLOAT_EXTENSION_IF_BROKEN

Ab Safari 8 (als WebGL in Safari eingeführt wurde) sind die Erweiterungen OES_texture_half_float und OES_texture_half_float_linear fehlerhaft und funktionieren nicht korrekt, wenn sie als Quelltexturen verwendet werden. Siehe https://bugs.webkit.org/show_bug.cgi?id=183321, https://bugs.webkit.org/show_bug.cgi?id=169999, https://stackoverflow.com/questions/54248633/cannot-create-half-float-oes-texture-from-uint16array-on-ipad

Standardwert: false

GL_WORKAROUND_SAFARI_GETCONTEXT_BUG

Workaround für das Safari WebGL-Problem: Nach dem erfolgreichen Abrufen eines WebGL-Kontexts auf einem Canvas gibt der Aufruf von .getContext() immer diesen Kontext zurück, unabhängig davon, welche 'webgl'- oder 'webgl2'-Kontextversion übergeben wurde. Siehe https://bugs.webkit.org/show_bug.cgi?id=222758 und https://github.com/emscripten-core/emscripten/issues/13295. Setzen Sie dies auf 0, um den Workaround zwangsweise zu deaktivieren, wenn Sie wissen, dass das Problem Sie nicht betrifft.

Standardwert: true

GL_ENABLE_GET_PROC_ADDRESS

Wenn 1, Verlinkung mit Unterstützung für glGetProcAddress()-Funktionalität. In WebGL verursacht glGetProcAddress() einen erheblichen Code-Größen- und Performance-Impact, da WebGL eine solche Funktionalität nicht nativ bereitstellt und sie emuliert werden muss. Die Verwendung von glGetProcAddress() wird nicht empfohlen. Wenn Sie dies dennoch benötigen, z.B. beim Portieren eines bestehenden Renderers, können Sie mit -sGL_ENABLE_GET_PROC_ADDRESS=1 linken, um Unterstützung für diese Funktionalität zu erhalten.

Standardwert: true

JS_MATH

Verwenden Sie JavaScript-Mathematikfunktionen wie Math.tan. Dies spart Code-Größe, da wir die Lieferung von kompiliertem Musl-Code vermeiden können. Es kann jedoch erheblich langsamer sein, da es JS aufruft. Es kann auch unterschiedliche Ergebnisse liefern, da JS-Mathematik etwas anders als libc spezifiziert ist und auch zwischen Browsern variieren kann.

Standardwert: false

POLYFILL_OLD_MATH_FUNCTIONS

Wenn gesetzt, aktiviert Polyfilling für Math.clz32, Math.trunc, Math.imul, Math.fround.

Standardwert: false

LEGACY_VM_SUPPORT

Setzen Sie dies, um Kompatibilitätsemulationen für alte JavaScript-Engines zu aktivieren. Dies gibt Ihnen die höchstmögliche Wahrscheinlichkeit, dass der Code überall funktioniert, selbst in seltenen alten Browsern und Shell-Umgebungen. Speziell:

• Fügen Sie Polyfilling für Math.clz32, Math.trunc, Math.imul, Math.fround hinzu. (-sPOLYFILL_OLD_MATH_FUNCTIONS)

• Deaktivieren Sie WebAssembly. (Muss mit -sWASM=0 gekoppelt sein)

• Passt die MIN_X_VERSION-Einstellungen auf 0 an, um die Unterstützung für alle Browserversionen einzuschließen.

• Vermeiden Sie TypedArray.fill, falls erforderlich, in der Hilfsfunktion zeroMemory.

Sie können die oben genannten Optionen auch einzeln konfigurieren.

Standardwert: false

ENVIRONMENT

Gibt an, in welchen Laufzeitumgebungen die JS-Ausgabe ausgeführt werden kann. Für maximale Portabilität kann dies so konfiguriert werden, dass alle Umgebungen unterstützt werden, oder es kann begrenzt werden, um die gesamte Code-Größe zu reduzieren. Die unterstützten Umgebungen sind:

• 'web' - die normale Webumgebung.

• 'webview' - genau wie Web, aber in einem Webview wie Cordova; wird in fast allen Fällen als identisch mit "web" betrachtet.

• 'worker' - eine Web Worker-Umgebung.

• 'node' - Node.js.

• 'shell' - eine JS-Shell wie d8, js oder jsc.

Diese Einstellung kann eine kommagetrennte Liste dieser Umgebungen sein, z.B. "web,worker". Wenn dies ein leerer String ist, werden alle Umgebungen unterstützt.

Beachten Sie, dass die hier erkannte Menge von Umgebungen nicht identisch ist mit denen, die wir zur Laufzeit mit ENVIRONMENT_IS_* identifizieren. Insbesondere

• Wir erkennen zur Laufzeit, ob wir ein Pthread sind, aber das ist für Worker und nicht für die Hauptdatei gesetzt, daher würde es hier keinen Sinn machen, dies anzugeben.

• Das Webview-Ziel ist im Grunde eine Untermenge des Webs. Es muss zusammen mit Web angegeben werden (z. B. "web,webview") und wir verwenden es nur für die Codegenerierung zur Kompilierzeit, es gibt keine Laufzeitverhaltensänderung.

Beachten Sie, dass wir standardmäßig die 'shell'-Umgebung nicht einschließen, da die direkte Verwendung von d8, js, jsc extrem selten ist.

Standardwert: 'web,webview,worker,node'

LZ4

Aktiviert die Unterstützung für LZ4-komprimierte Dateipakete. Sie werden komprimiert im Speicher gespeichert und bei Bedarf dekomprimiert, wodurch vermieden wird, die gesamten dekomprimierten Daten auf einmal im Speicher zu speichern. Wenn Sie den Dateipacker separat ausführen, müssen Sie das Hauptprogramm trotzdem mit diesem Flag erstellen und auch –lz4 an den Dateipacker übergeben. (Sie können eine Datei auch manuell auf dem Client mit LZ4.loadPackage() komprimieren, dies wird jedoch weniger empfohlen.) Einschränkungen:

• LZ4-komprimierte Dateien werden nur bei Bedarf dekomprimiert, daher stehen sie für spezielle Preloading-Operationen wie das Vordecodieren von Bildern mit Browser-Codecs, preloadPlugin-Stuff usw. nicht zur Verfügung.

• LZ4-Dateien sind schreibgeschützt.

Standardwert: false

DISABLE_EXCEPTION_CATCHING

Deaktiviert die Generierung von Code zum tatsächlichen Abfangen von Ausnahmen. Diese Deaktivierung ist standardmäßig aktiviert, da der Overhead von Ausnahmen in Bezug auf Größe und Geschwindigkeit derzeit recht hoch ist (in Zukunft sollte wasm dies verbessern). Wenn Ausnahmen deaktiviert sind, wird eine Ausnahme, wenn sie tatsächlich auftritt, nicht abgefangen und das Programm wird angehalten (dies führt also nicht zu stillen Fehlern).

Hinweis

Dies entfernt das Abfangen von Ausnahmen, was das Hauptproblem für die Geschwindigkeit ist, aber Sie sollten Quellcode-Dateien mit -fno-exceptions erstellen, um wirklich alle Ausnahmen-Code-Overheads zu beseitigen, da sie möglicherweise geworfene Ausnahmen enthalten, die nie abgefangen werden (z.B. kann allein die Verwendung von std::vector dies verursachen). -fno-rtti kann ebenfalls helfen.

Diese Option ist mit EXCEPTION_CATCHING_ALLOWED gegenseitig ausschließend.

Diese Option gilt nur für die Emscripten (JavaScript-basierte) Ausnahmebehandlung und steuert nicht die native Wasm-Ausnahmebehandlung.

[kompilieren+linken] - beeinflusst den Benutzercode beim Kompilieren und Systembibliotheken beim Linken

Standardwert: 1

EXCEPTION_CATCHING_ALLOWED

Ermöglicht das Abfangen von Ausnahmen, jedoch nur in den aufgelisteten Funktionen. Diese Option wirkt wie eine präzisere Version von DISABLE_EXCEPTION_CATCHING=0.

Diese Option ist mit DISABLE_EXCEPTION_CATCHING gegenseitig ausschließend.

Diese Option gilt nur für die Emscripten (JavaScript-basierte) Ausnahmebehandlung und steuert nicht die native Wasm-Ausnahmebehandlung.

[kompilieren+linken] - beeinflusst den Benutzercode beim Kompilieren und Systembibliotheken beim Linken

Standardwert: []

DISABLE_EXCEPTION_THROWING

Intern: Verfolgt, ob Emscripten die Support-Bibliothek für das Werfen von Ausnahmen (C++ 'throw') einbinden soll. Dies muss nicht direkt gesetzt werden, aber übergeben Sie -fno-exceptions an den Build, um die Unterstützung für Ausnahmen zu deaktivieren. (Dies ist im Grunde -fno-exceptions, wird aber zur finalen Linkzeit anstelle der Kompilierzeit einzelner .cpp-Dateien überprüft.) Wenn das Programm wirklich Code zum Werfen von Ausnahmen enthält (einige Quelldateien wurden nicht mit -fno-exceptions kompiliert) und dieses Flag zur Linkzeit gesetzt ist, erhalten Sie Fehler über undefinierte Symbole, da der Code zum Werfen von Ausnahmen nicht eingebunden wird. In diesem Fall sollten Sie entweder die Option aufheben (wenn Sie Ausnahmen wünschen) oder die Kompilierung der Quelldateien korrigieren, damit tatsächlich keine Ausnahmen verwendet werden. TODO(sbc): In settings_internal verschieben (derzeit blockiert aufgrund der Verwendung in Testcode).

Diese Option gilt nur für die Emscripten (JavaScript-basierte) Ausnahmebehandlung und steuert nicht die native Wasm-Ausnahmebehandlung.

Standardwert: false

EXPORT_EXCEPTION_HANDLING_HELPERS

Macht die Funktion zur Ausgabe von Ausnahmemeldungen, 'getExceptionMessage', in der JS-Bibliothek zur Verwendung verfügbar, indem notwendige Symbole zu EXPORTED_FUNCTIONS hinzugefügt werden.

Dies funktioniert sowohl mit Emscripten EH als auch mit Wasm EH. Wenn Sie eine Ausnahme von JS abfangen, erhalten Sie im Falle von Emscripten EH einen vom Benutzer geworfenen Wert und im Falle von Wasm EH ein WebAssembly.Exception-Objekt. 'getExceptionMessage' nimmt im Falle von Emscripten EH den vom Benutzer geworfenen Wert und im Falle von Wasm EH das WebAssembly.Exception-Objekt, was bedeutet, dass Sie in beiden Fällen eine abgefangene Ausnahme direkt an die Funktion übergeben können.

Bei Verwendung mit Wasm EH bietet diese Option zusätzlich die folgenden Funktionen in der JS-Bibliothek:

• getCppExceptionTag: Gibt den C++-Tag zurück

• getCppExceptionThrownObjectFromWebAssemblyException: Gibt bei einem WebAssembly.Exception-Objekt die tatsächliche Adresse des vom Benutzer geworfenen C++-Objekts im Wasm-Speicher zurück.

Das Setzen dieser Option fügt auch Funktionen zum Erhöhen und Verringern der Referenzzählung ('incrementExceptionRefcount' und 'decrementExceptionRefcount') in der JS-Bibliothek hinzu, da Sie, wenn Sie eine Ausnahme von JS abfangen, die Referenzzählung manuell manipulieren müssen, um Speicherlecks zu vermeiden. Was Sie tun müssen, hängt von der Art der von Ihnen verwendeten EH ab (https://github.com/emscripten-core/emscripten/issues/17115).

Siehe test_EXPORT_EXCEPTION_HANDLING_HELPERS in test/test_core.py für ein Anwendungsbeispiel.

Standardwert: false

EXCEPTION_STACK_TRACES

Wenn dies aktiviert ist, enthalten Ausnahmen Stack-Traces, und ungefangene Ausnahmen zeigen beim Beenden Stack-Traces an. Dies ist standardmäßig true, wenn ASSERTIONS aktiviert ist. Diese Option ist für Benutzer gedacht, die Stack-Traces von Ausnahmen wünschen, aber die anderen Overheads, die ASSERTIONS verursachen können, nicht möchten. Diese Option impliziert EXPORT_EXCEPTION_HANDLING_HELPERS.

Standardwert: false

WASM_EXNREF

Gibt Anweisungen für den neuen Wasm-Ausnahmebehandlungsvorschlag mit exnref aus, der im Oktober 2023 angenommen wurde. Die Implementierung des neuen Vorschlags ist noch im Gange und diese Funktion ist derzeit experimentell.

Standardwert: false

NODEJS_CATCH_EXIT

Emscripten wirft eine ExitStatus-Ausnahme, um beim Aufruf von exit() abzuwickeln. Ohne diese Einstellung kann dies als eine unbehandelte Ausnahme der obersten Ebene auftreten.

Mit dieser Einstellung wird ein globaler uncaughtException-Handler verwendet, um ExitStatus-Ausnahmen abzufangen und zu behandeln. Dies bedeutet jedoch, dass alle anderen unbehandelten Ausnahmen ebenfalls abgefangen und erneut geworfen werden, was nicht immer wünschenswert ist.

Standardwert: false

NODEJS_CATCH_REJECTION

Fängt unbehandelte Ablehnungen in Node ab. Dies betrifft nur Node-Versionen, die älter als 15 sind. Ohne dies gibt die alte Node-Version eine Warnung aus, beendet sich aber mit dem Rückgabecode Null. Mit dieser Einstellung behandeln wir jede unbehandelte Ablehnung und werfen eine Ausnahme, was dazu führt, dass der Prozess sofort mit einem Rückgabecode ungleich Null beendet wird. Dies ist in Node 15+ nicht erforderlich, daher wird diese Einstellung standardmäßig auf false gesetzt, wenn MIN_NODE_VERSION 150000 oder höher ist.

Standardwert: true

ASYNCIFY

Ob asynchrone Operationen im kompilierten Code unterstützt werden sollen. Dies ermöglicht es, JS-Funktionen aus synchron erscheinendem Code in C/C++ aufzurufen.

• 1 (Standard): Führt Binaryens Asyncify-Pass aus, um den Code mit Asyncify zu transformieren. Dies erzeugt am Ende eine normale wasm-Datei, so dass es überall funktioniert, aber es hat erhebliche Kosten in Bezug auf Code-Größe und Geschwindigkeit. Siehe https://emscripten.de/docs/porting/asyncify.html

• 2 (veraltet): Verwenden Sie stattdessen -sJSPI.

Standardwert: 0

ASYNCIFY_IMPORTS

Importe, die eine asynchrone Operation durchführen können, zusätzlich zu den Standardimporten, die Emscripten wie emscripten_sleep definiert. Wenn Sie weitere hinzufügen, müssen Sie diese hier erwähnen, sonst funktionieren sie nicht (in ASSERTIONS-Builds wird ein Fehler angezeigt). Beachten Sie, dass diese Liste früher die Standardimporten enthielt, was bedeutete, dass Sie diese auflisten mussten, wenn Sie Ihre eigenen hinzufügten; die Standardimporten werden jetzt automatisch hinzugefügt.

Standardwert: []

ASYNCIFY_IGNORE_INDIRECT

Ob indirekte Aufrufe während eines Unwinds/Rewinds auf dem Stack sein können. Wenn Sie wissen, dass dies nicht der Fall ist, kann das Setzen dieser Option äußerst hilfreich sein, da Asyncify sonst annehmen muss, dass ein indirekter Aufruf fast überall hinkommen kann.

Standardwert: false

ASYNCIFY_STACK_SIZE

Die Größe des Asyncify-Stacks – der Bereich, der zur Speicherung von Unwind-/Rewind-Informationen verwendet wird. Dieser muss groß genug sein, um den Aufrufstack und lokale Variablen zu speichern. Wenn er zu klein ist, sehen Sie einen Wasm-Trap aufgrund der Ausführung einer "unerreichbaren" Anweisung. In diesem Fall sollten Sie diese Größe erhöhen.

Standardwert: 4096

ASYNCIFY_REMOVE

Wenn die Asyncify-Entfernungsliste bereitgestellt wird, werden die darin enthaltenen Funktionen nicht instrumentiert, selbst wenn es so aussieht, als ob sie es müssten. Dies kann nützlich sein, wenn Sie Dinge wissen, die die Ganz-Programm-Analyse nicht weiß, z. B. wenn Sie wissen, dass bestimmte indirekte Aufrufe sicher sind und nicht entladen werden. Aber wenn Sie die Liste falsch erstellen, werden Dinge kaputtgehen (und in einem Produktions-Build kann Benutzereingabe Code-Pfade erreichen, die Sie während des Testens übersehen haben, so dass es schwierig ist zu wissen, ob Sie dies richtig gemacht haben), daher wird dies nicht empfohlen, es sei denn, Sie wissen wirklich, was Sie tun, und müssen jedes bisschen Geschwindigkeit und Größe optimieren.

Die Namen in dieser Liste sind Namen aus dem WebAssembly Names-Abschnitt. Das wasm-Backend wird diese Namen in menschenlesbarer Form anstelle der typischen C++-Mangling-Form ausgeben. Sie sollten beispielsweise Struct::func() anstelle von _ZN6Struct4FuncEv schreiben. C unterscheidet sich auch von C++, da C-Namen nicht mit Parametern enden; daher würde foo(int) in C++ in C einfach als foo erscheinen (C++ hat Parameter, weil es überladene Funktionen unterscheiden muss). Sie sehen Warnungen in der Konsole, wenn ein Name in der Liste fehlt (dies sind keine Fehler, da Inlining usw. Änderungen verursachen können, die bedeuten würden, dass eine einzelne Liste nicht für -O0- und -O1-Builds usw. funktionieren könnte). Sie können das wasm-Binärprogramm untersuchen, um nach den tatsächlichen Namen zu suchen, entweder direkt oder mithilfe von wasm-objdump oder wasm-dis usw.

Einfache *-Wildcard-Übereinstimmung wird unterstützt.

Um die Einschränkungen in Betriebssystem-Shells oder Build-System-Escaping zu vermeiden, können folgende Ersetzungen vorgenommen werden:

• ' ' -> .,

• & -> #,

• , -> ?.

Das heißt, die Funktion "foo(char const*, int&)" kann stattdessen als "foo(char.const*?.int#)" in der Befehlszeile eingegeben werden.

Hinweis: Leerzeichen sind Teil der Funktionssignatur! D.h. "foo(char const *, int &)" stimmt nicht mit "foo(char const*, int&)" überein, und auch nicht mit "foo(const char*, int &)".

Standardwert: []

ASYNCIFY_ADD

Funktionen in der Asyncify-Add-Liste werden der Liste der instrumentierten Funktionen hinzugefügt, d.h. sie werden instrumentiert, auch wenn Asyncify sonst der Meinung ist, dass sie es nicht tun müssen. Da standardmäßig alles auf die sicherste Weise instrumentiert wird, ist dies nur nützlich, wenn Sie IGNORE_INDIRECT verwenden und diese Liste verwenden, um einige indirekte Aufrufe zu korrigieren, die tatsächlich instrumentiert werden müssen.

Siehe Hinweise zu ASYNCIFY_REMOVE bezüglich der Namen, einschließlich Wildcard-Übereinstimmung und Zeichenersetzungen.

Standardwert: []

ASYNCIFY_PROPAGATE_ADD

Wenn aktiviert, wird der Instrumentierungsstatus von der Add-Liste weitergegeben, d.h. deren Aufrufer, und die Aufrufer deren Aufrufer und so weiter. Wenn deaktiviert, müssen alle Aufrufer manuell zur Add-Liste hinzugefügt werden (wie die Only-Liste).

Standardwert: true

ASYNCIFY_ONLY

Wenn die Asyncify-Nur-Liste bereitgestellt wird, werden nur die Funktionen in der Liste instrumentiert. Wie bei der Entfernungsliste führt ein Fehler hier zum Absturz Ihrer Anwendung.

Siehe Hinweise zu ASYNCIFY_REMOVE bezüglich der Namen, einschließlich Wildcard-Übereinstimmung und Zeichenersetzungen.

Standardwert: []

ASYNCIFY_ADVISE

Wenn aktiviert, wird ausgegeben, welche Funktionen instrumentiert wurden und warum.

Standardwert: false

ASYNCIFY_LAZY_LOAD_CODE

Ermöglicht das verzögerte Laden von Code: Dort, wo emscripten_lazy_load_code() geschrieben ist, wird die Ausführung angehalten, der restliche Code geladen und dann fortgesetzt.

Standardwert: false

ASYNCIFY_DEBUG

Laufzeit-Debug-Logging aus Asyncify-Interna.

• 1: Minimale Protokollierung.

• 2: Ausführliche Protokollierung.

Standardwert: 0

ASYNCIFY_EXPORTS

Veraltet, verwenden Sie stattdessen JSPI_EXPORTS.

Hinweis

Diese Einstellung ist veraltet

Standardwert: []

JSPI

Verwenden Sie VM-Unterstützung für den JavaScript Promise Integration-Vorschlag. Dies ermöglicht asynchrone Operationen ohne den Overhead der Modifizierung des Wasm. Dies ist derzeit experimentell, während die Spezifikationsdiskussion noch läuft, siehe https://github.com/WebAssembly/js-promise-integration/ TODO: Dokumentieren Sie, welche der folgenden Flags in diesem Modus noch relevant sind (z.B. IGNORE_INDIRECT usw. werden nicht benötigt)

Standardwert: 0

JSPI_EXPORTS

Eine Liste von exportierten Modulfunktionen, die asynchron sein werden. Jeder Export wird ein Promise zurückgeben, das mit dem Ergebnis aufgelöst wird. Alle Exporte, die einen asynchronen Import (aufgelistet in JSPI_IMPORTS) aufrufen, müssen hier enthalten sein.

Standardmäßig enthält dies main.

Standardwert: []

JSPI_IMPORTS

Eine Liste von importierten Modulfunktionen, die potenziell asynchrone Arbeit leisten werden. Die importierte Funktion sollte ein Promise zurückgeben, wenn sie asynchrone Arbeit leistet.

Hinweis bei Verwendung von --js-library: Die Funktion kann stattdessen in der Bibliothek mit <function_name>_async:: true markiert werden, anstatt diese Einstellung zu verwenden.

Standardwert: []

EXPORTED_RUNTIME_METHODS

Laufzeitelemente, die standardmäßig auf dem Modul exportiert werden. Früher haben wir hier ziemlich viel exportiert, aber alles entfernt. Sie sollten EXPORTED_RUNTIME_METHODS für Dinge verwenden, die Sie von der Laufzeit exportieren möchten. Beachten Sie, dass der Name etwas irreführend sein kann, da dies für jedes JS-Bibliothekselement gilt und nicht nur für Methoden. Zum Beispiel können wir das FS-Objekt exportieren, indem wir "FS" in dieser Liste haben.

Standardwert: []

EXTRA_EXPORTED_RUNTIME_METHODS

Veraltet, verwenden Sie stattdessen EXPORTED_RUNTIME_METHODS.

Hinweis

Diese Einstellung ist veraltet

Standardwert: []

INCOMING_MODULE_JS_API

Eine Liste der eingehenden Werte auf dem Module-Objekt in JS, die uns interessieren. Wenn ein Wert nicht in dieser Liste ist, geben wir keinen Code aus, um zu prüfen, ob Sie ihn auf dem Module-Objekt bereitstellen. Wenn Sie zum Beispiel Folgendes haben:

var Module = {
  print: (x) => console.log('print: ' + x),
  preRun: [() => console.log('pre run')]
};

Dann muss MODULE_JS_API 'print' und 'preRun' enthalten; wenn nicht, geben wir möglicherweise keinen Code aus, um diesen Wert zu lesen und zu verwenden. Mit anderen Worten, diese Option ermöglicht es Ihnen, statisch zur Kompilierzeit die Liste der Module-JS-Werte festzulegen, die Sie zur Laufzeit bereitstellen werden, damit der Compiler besser optimieren kann.

Das Setzen dieser Liste auf [], oder zumindest auf eine kurze und prägnante Menge von Namen, die Sie tatsächlich verwenden, kann sehr nützlich sein, um die Code-Größe zu reduzieren. Standardmäßig enthält die Liste eine Reihe häufig verwendeter Symbole.

FIXME: sollte dies einfach 0 sein, wenn wir alles wollen?

Standardwert: (mehrzeiliger Wert, siehe settings.js)

CASE_INSENSITIVE_FS

Wenn auf ungleich Null gesetzt, wird das bereitgestellte virtuelle Dateisystem als nicht-groß-/kleinschreibungssensitiv behandelt, wie es Windows und macOS tun. Wenn auf 0 gesetzt, ist das VFS groß-/kleinschreibungssensitiv, wie unter Linux.

Standardwert: false

FILESYSTEM

Wenn auf 0 gesetzt, wird keine Dateisystemunterstützung eingebaut. Nützlich, wenn Sie nur reine Berechnungen durchführen, aber keine Dateien lesen oder Streams verwenden (einschließlich fprintf und andere stdio.h-Elemente) oder ähnliches. Die einzige Ausnahme ist eine teilweise Unterstützung für printf und puts, auf hackige Weise. Der Compiler wird dies automatisch setzen, wenn er erkennt, dass die syscall-Nutzung (die statisch ist) kein vollständiges Dateisystem erfordert. Wenn Sie dennoch Dateisystemunterstützung wünschen, verwenden Sie FORCE_FILESYSTEM.

Standardwert: true

FORCE_FILESYSTEM

Bewirkt, dass die vollständige Dateisystemunterstützung eingeschlossen wird, auch wenn statisch der Eindruck entsteht, dass sie nicht verwendet wird. Wenn Ihr C-Code beispielsweise keine Dateien verwendet, Sie aber JS-Code einbinden, der dies tut, benötigen Sie dies möglicherweise.

Standardwert: false

NODERAWFS

Ermöglicht die Unterstützung für das NODERAWFS-Dateisystem-Backend. Dies ist ein spezielles Backend, da es alle normalen Dateisystemzugriffe durch direkte Node.js-Operationen ersetzt, ohne dass FS.mount() erforderlich ist, und dieses Backend funktioniert nur mit Node.js. Das anfängliche Arbeitsverzeichnis ist dasselbe wie process.cwd() anstelle des VFS-Stammverzeichnisses. Da dieser Modus Node.js direkt verwendet, um auf das reale lokale Dateisystem Ihres Betriebssystems zuzugreifen, ist der Code nicht unbedingt zwischen Betriebssystemen portierbar – er ist so portierbar, wie ein Node.js-Programm es wäre, was bedeutet, dass Unterschiede in der Art und Weise, wie das zugrunde liegende Betriebssystem Berechtigungen und Fehler usw. behandelt, spürbar sein können.

Standardwert: false

NODE_CODE_CACHING

Dies speichert das kompilierte WASM-Modul in einer Datei mit dem Namen $WASM_BINARY_NAME.$V8_VERSION.cached und lädt es bei nachfolgenden Ausführungen. Dies cacht den kompilierten WASM-Code von V8 in Node, was das Kompilieren bei nachfolgenden Ausführungen spart und diese viel schneller starten lässt. Die in Node verwendete V8-Version ist im Cache-Namen enthalten, damit wir nicht versuchen, zwischengespeicherten Code von einer anderen Version zu laden, was stillschweigend fehlschlägt (es scheint in Ordnung zu laden, aber wir kompilieren tatsächlich neu).

• Die einzige Version, die sicher funktioniert, ist Node 12.9.1, da dies zurückgegangen ist, siehe https://github.com/nodejs/node/issues/18265#issuecomment-622971547

• Der Standardspeicherort der .cached-Dateien ist neben dem WASM-Binärprogramm, wie zuvor erwähnt. Wenn sich dieser in einem schreibgeschützten Verzeichnis befindet, müssen Sie sie möglicherweise an einem anderen Ort ablegen. Sie können den locateFile()-Hook dazu verwenden.

Standardwert: false

EXPORTED_FUNCTIONS

Symbole, die explizit exportiert werden. Diese Symbole bleiben durch die LLVM Dead Code Elimination erhalten und sind auch außerhalb des generierten Codes zugänglich, selbst nach dem Ausführen des Closure Compilers (auf "Module"). Native Symbole, die hier aufgeführt sind, erfordern ein _-Präfix.

Standardmäßig wird, wenn diese Einstellung nicht in der Befehlszeile angegeben wird, die Funktion _main implizit exportiert. Im STANDALONE_WASM-Modus ist der Standardexport __start (oder __initialize, wenn –no-entry angegeben ist).

JS-Bibliothekssymbole können ebenfalls zu dieser Liste hinzugefügt werden (ohne das führende $).

Standardwert: []

EXPORT_ALL

Wenn true, exportieren wir alle im JS vorhandenen Symbole auf das Module-Objekt. Dies beeinflusst nicht, welche Symbole vorhanden sein werden – es verhindert weder DCE noch führt es dazu, dass etwas in die Verknüpfung einbezogen wird. Es führt nur Module['X'] = X; für alle X aus, die in der JS-Datei landen. Dies ist nützlich, um die JS-Bibliotheksfunktionen auf Module zu exportieren, für Dinge wie dynamisches Verknüpfen.

Standardwert: false

EXPORT_KEEPALIVE

Wenn wahr, exportieren wir die im JS vorhandenen Symbole auf das Module-Objekt. Es macht nur Module['X'] = X;

Standardwert: true

RETAIN_COMPILER_SETTINGS

Speichert die Werte dieser Einstellungen und macht sie über getCompilerSetting und emscripten_get_compiler_setting zugänglich. Um zu sehen, was beibehalten wird, suchen Sie im generierten Code nach compilerSettings.

Standardwert: false

DEFAULT_LIBRARY_FUNCS_TO_INCLUDE

JS-Bibliothekselemente (in JS implementierte C-Funktionen), die wir standardmäßig einschließen. Wenn Sie sicherstellen möchten, dass etwas vom JS-Compiler eingeschlossen wird, fügen Sie es hier hinzu. Wenn Sie beispielsweise keinen emscripten_* C-API-Aufruf von C verwenden, aber ihn von JS aus aufrufen möchten, fügen Sie ihn hier hinzu. Beachten Sie, dass der Name etwas irreführend sein kann, da dies für jedes JS-Bibliothekselement und nicht nur für Funktionen gilt. Sie können beispielsweise das Browser-Objekt einschließen, indem Sie "$Browser" zu dieser Liste hinzufügen.

Wenn Sie ein JS-Bibliothekssymbol sowohl einschließen als auch exportieren möchten, genügt es, es einfach zu EXPORTED_FUNCTIONS hinzuzufügen, ohne es zusätzlich zu DEFAULT_LIBRARY_FUNCS_TO_INCLUDE hinzuzufügen.

Standardwert: []

INCLUDE_FULL_LIBRARY

Schließt alle JS-Bibliotheksfunktionen ein, anstatt der Summe von DEFAULT_LIBRARY_FUNCS_TO_INCLUDE + alle vom generierten Code verwendeten Funktionen. Dies ist erforderlich, wenn Module dynamisch geladen werden (d.h. dlopen), die Laufzeitbibliotheksfunktionen verwenden, die im Hauptmodul nicht verwendet werden. Beachten Sie, dass dies nur für JS-Bibliotheken gilt, nicht für C. Sie müssen die Hauptdatei so gestalten, dass sie alle benötigten C-Bibliotheken enthält. Wenn ein Modul beispielsweise malloc oder new verwendet, müssen Sie diese auch in der Hauptdatei verwenden, um malloc für das Modul verfügbar zu machen.

Standardwert: false

RELOCATABLE

Wenn auf 1 gesetzt, geben wir verschiebbaren Code vom LLVM-Backend aus; sowohl globale Variablen als auch Funktionszeiger werden alle versetzt (jeweils um gb und fp). Wird automatisch für SIDE_MODULE oder MAIN_MODULE gesetzt.

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

MAIN_MODULE

Ein Hauptmodul ist eine Datei, die so kompiliert wurde, dass wir sie zur Laufzeit mit einem Nebenmodul verknüpfen können.

• 1: Normales Hauptmodul.

• 2: DCE'd Hauptmodul. Wir eliminieren toten Code normal. Wenn ein Nebenmodul etwas vom Hauptmodul benötigt, liegt es an Ihnen sicherzustellen, dass es am Leben bleibt.

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: 0

SIDE_MODULE

Entspricht MAIN_MODULE (unterstützt auch die Modi 1 und 2)

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: 0

RUNTIME_LINKED_LIBS

Veraltet, listen Sie stattdessen freigegebene Bibliotheken direkt in der Befehlszeile auf.

Hinweis

Diese Einstellung ist veraltet

Standardwert: []

BUILD_AS_WORKER

Wenn auf 1 gesetzt, handelt es sich um eine Worker-Bibliothek, eine spezielle Art von Bibliothek, die in einem Worker ausgeführt wird. Siehe emscripten.h

Standardwert: false

PROXY_TO_WORKER

Wenn auf 1 gesetzt, erstellen wir das Projekt in einer JS-Datei, die in einem Worker ausgeführt wird, und generieren eine HTML-Datei, die Eingabe und Ausgabe an/von diesem Worker weiterleitet.

Standardwert: false

PROXY_TO_WORKER_FILENAME

Wenn gesetzt, der Dateiname des Skripts, das der Hauptthread lädt. Nützlich, wenn Ihr Projekt das von Emscripten generierte Hauptskript nicht sofort ausführt, sondern vorher einige Einstellungen vornimmt.

Standardwert: ''

PROXY_TO_PTHREAD

Wenn auf 1 gesetzt, wird ein kleiner Stub-main() zwischen dem echten main() kompiliert, der pthread_create() aufruft, um die Anwendungs-main() in einem Pthread auszuführen. Dies können Anwendungen auch manuell tun, wenn sie möchten, diese Option wird als Bequemlichkeit bereitgestellt.

Das Pthread, auf dem main() läuft, ist in jeder Hinsicht ein normales Pthread, mit dem einzigen Unterschied, dass seine Stackgröße der des Hauptthreads entspricht, d.h. STACK_SIZE. Dies macht es einfach, zwischen PROXY_TO_PTHREAD- und Nicht-PROXY_TO_PTHREAD-Modi zu wechseln, wobei main() immer die gleiche Stackgröße erhält.

Dies leitet Module['canvas'] weiter, falls vorhanden und wenn OFFSCREENCANVAS_SUPPORT aktiviert ist. Dies muss geschehen, da dies die einzige Möglichkeit ist – dieser Browser-Hauptthread führt den einzigen pthread_create-Aufruf aus, der in diesem Thread stattfindet, daher ist dies die einzige Möglichkeit, den Canvas von dort zu übertragen.

Standardwert: false

LINKABLE

Wenn auf 1 gesetzt, geben wir verknüpfbaren Code vom LLVM-Backend aus; sowohl globale als auch Funktionszeiger werden alle versetzt (jeweils um gb und fp). Dies bedeutet, dass wir alle Symbole nicht internalisieren und die ungenutzten nicht entfernen, mit anderen Worten, wir werden ungenutzte Funktionen und globale Variablen nicht entfernen, die von einem anderen Modul, mit dem wir verknüpft sind, verwendet werden könnten.

MAIN_MODULE und SIDE_MODULE implizieren dies beide, so dass es normalerweise nicht notwendig ist, dies explizit zu setzen. Beachten Sie, dass MAIN_MODULE und SIDE_MODULE Modus 2 dies nicht setzen, so dass wir immer noch normale DCE an ihnen durchführen, und in diesem Fall müssen Sie relevante Dinge selbst durch Exportieren am Leben erhalten.

Standardwert: false

STRICT

Emscripten 'strict' Build-Modus: Unterstützung für veraltete Build-Optionen wird eingestellt. Setzen Sie die Umgebungsvariable EMCC_STRICT=1 oder übergeben Sie -sSTRICT, um zu testen, ob eine Codebasis in vorwärtskompatibler Weise ordnungsgemäß erstellt wird. Aktivierte Änderungen hierdurch:

• Das C-Define EMSCRIPTEN ist nicht definiert (__EMSCRIPTEN__ ist es immer, und ist das Richtige zu verwenden).

• STRICT_JS ist aktiviert.

• IGNORE_MISSING_MAIN ist deaktiviert.

• AUTO_JS_LIBRARIES ist deaktiviert.

• AUTO_NATIVE_LIBRARIES ist deaktiviert.

• DEFAULT_TO_CXX ist deaktiviert.

• USE_GLFW ist standardmäßig auf 0 statt auf 2 gesetzt.

• ALLOW_UNIMPLEMENTED_SYSCALLS ist deaktiviert.

• INCOMING_MODULE_JS_API ist standardmäßig auf leer gesetzt.

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

IGNORE_MISSING_MAIN

Erlaubt dem Programm, mit oder ohne main-Symbol zu linken. Wenn dies deaktiviert ist, muss man ein main-Symbol bereitstellen oder explizit durch Übergabe von --no-entry oder einer EXPORTED_FUNCTIONS-Liste, die _main nicht enthält, ablehnen.

Standardwert: true

STRICT_JS

Fügt "use strict;" zum generierten JS hinzu

Standardwert: false

WARN_ON_UNDEFINED_SYMBOLS

Wenn auf 1 gesetzt, werden wir bei allen undefinierten Symbolen warnen, die nicht von den library_*.js-Dateien aufgelöst werden. Beachten Sie, dass es in großen Projekten üblich ist, nicht alles zu implementieren, wenn Sie wissen, was tatsächlich nicht aufgerufen wird (und sich nicht mit dem bestehenden Build-System herumschlagen möchten), und Funktionen später implementiert werden könnten, z.B. in –pre-js, so dass Sie möglicherweise mit -s WARN_ON_UNDEFINED_SYMBOLS=0 bauen möchten, um die Warnungen zu deaktivieren, wenn sie Sie stören. Siehe auch ERROR_ON_UNDEFINED_SYMBOLS. Alle undefinierten Symbole, die in EXPORTED_FUNCTIONS aufgeführt sind, werden ebenfalls gemeldet.

Standardwert: true

ERROR_ON_UNDEFINED_SYMBOLS

Wenn auf 1 gesetzt, geben wir einen Linkzeitfehler bei allen undefinierten Symbolen aus (siehe WARN_ON_UNDEFINED_SYMBOLS). Um undefinierte Symbole zur Linkzeit zuzulassen, setzen Sie dies auf 0; in diesem Fall tritt ein Laufzeitfehler auf, wenn eine undefinierte Funktion aufgerufen wird. Alle undefinierten Symbole, die in EXPORTED_FUNCTIONS aufgeführt sind, werden ebenfalls gemeldet.

Standardwert: true

SMALL_XHR_CHUNKS

Verwenden Sie kleine Chunk-Größe für binäre synchrone XHRs in Web Workern. Wird zum Testen verwendet. Siehe test_chunked_synchronous_xhr in runner.py und library.js.

Standardwert: false

HEADLESS

Wenn 1, wird Shim-Code eingeschlossen, der versucht, eine Browser-Umgebung zu „simulieren“, damit Sie ein Browser-Programm (z. B. mit SDL) in der Shell ausführen können. Offensichtlich wird nichts gerendert, aber dies kann für Benchmarking und Debugging nützlich sein, wenn das tatsächliche Rendering nicht das Problem ist. Beachten Sie, dass der Shim-Code sehr partiell ist – es ist schwer, einen ganzen Browser vorzutäuschen! – daher sollten Sie Ihre Erwartungen an die Funktionsfähigkeit gering halten.

Standardwert: false

DETERMINISTIC

Wenn 1, erzwingen wir, dass Date.now(), Math.random usw. deterministische Ergebnisse zurückgeben. Dies versucht auch, die Ausführung über Maschinen und Umgebungen hinweg deterministisch zu machen, indem beispielsweise nichts anderes basierend auf der Spracheinstellung des Browsers getan wird (was bedeuten würde, dass Sie in verschiedenen Browsern oder im Browser und in Node unterschiedliche Ergebnisse erhalten könnten). Gut zum Vergleichen von Builds für Debugging-Zwecke (und nichts anderem).

Standardwert: false

MODULARIZE

Standardmäßig geben wir den gesamten Code auf unkomplizierte Weise in die Ausgabedatei .js aus. Das bedeutet, dass, wenn Sie diese in einem Skript-Tag auf einer Webseite laden, sie den globalen Geltungsbereich verwendet. Wenn MODULARIZE gesetzt ist, geben wir den Code stattdessen in eine Funktion verpackt aus, die ein Promise zurückgibt. Das Promise wird mit der Modulinstanz aufgelöst, wenn es sicher ist, den kompilierten Code auszuführen, ähnlich dem onRuntimeInitialized-Callback. Sie müssen den onRuntimeInitialized-Callback nicht verwenden, wenn Sie MODULARIZE verwenden.

(Wenn WASM_ASYNC_COMPILATION ausgeschaltet ist, d.h. wenn die Kompilierung synchron ist, würde es keinen Sinn ergeben, ein Promise zurückzugeben, und stattdessen wird das Module-Objekt selbst zurückgegeben, das bereit zur Verwendung ist.)

Der Standardname der Funktion ist Module, kann aber mit der Option EXPORT_NAME geändert werden. Wir empfehlen, ihn in einen typischeren Namen für eine Factory-Funktion umzubenennen, z.B. createModule.

Sie verwenden die Factory-Funktion wie folgt:

const module = await EXPORT_NAME();

oder

let module;
EXPORT_NAME().then(instance => {
  module = instance;
});

Die Factory-Funktion akzeptiert 1 Parameter, ein Objekt mit Standardwerten für die Modulinstanz.

const module = await EXPORT_NAME({ option: value, ... });

Beachten Sie die Klammern – wir rufen EXPORT_NAME auf, um das Modul zu instanziieren. Dies ermöglicht es Ihnen, mehrere Instanzen des Moduls zu erstellen.

Beachten Sie, dass wir im MODULARIZE-Modus nicht nach einem globalen Module-Objekt für Standardwerte suchen. Standardwerte müssen als Parameter an die Factory-Funktion übergeben werden.

Die standardmäßige .html-Shell-Datei, die im MINIMAL_RUNTIME-Modus bereitgestellt wird, erstellt automatisch eine Singleton-Instanz, um die Anwendung auf der Seite auszuführen. (Beachten Sie, dass dies ohne Verwendung der zuvor erwähnten Promise-API geschieht und daher der Code für das Promise nicht einmal in der .js-Datei ausgegeben wird, wenn Sie emcc anweisen, eine .html-Ausgabe zu generieren.) Die standardmäßige .html-Shell-Datei, die im traditionellen Laufzeitmodus bereitgestellt wird, ist nur mit dem MODULARIZE=0-Modus kompatibel. Wenn Sie also mit dem traditionellen Laufzeitmodus bauen, sollten Sie Ihre eigene html-Shell-Datei bereitstellen, um die Instanziierung durchzuführen, wenn Sie mit MODULARIZE=1 bauen. (Weitere Details finden Sie unter https://github.com/emscripten-core/emscripten/issues/7950)

Wenn Sie --pre-js- oder --post-js-Dateien hinzufügen, werden diese zusammen mit dem restlichen Code innerhalb der Factory-Funktion eingeschlossen, um gemeinsam optimiert zu werden.

Wenn Sie Code außerhalb des gesamten generierten Codes, einschließlich der Factory-Funktion, einschließen möchten, können Sie –extern-pre-js oder –extern-post-js verwenden. Während –pre-js und –post-js dies im Nicht-MODULARIZE-Modus tun, ist ihre beabsichtigte Verwendung, Code hinzuzufügen, der mit dem Rest des ausgegebenen Codes optimiert wird, was eine bessere Eliminierung von totem Code und Minifizierung ermöglicht.

Standardwert: false

EXPORT_ES6

Exportiert mit einem ES6-Modul-Export anstelle eines UMD-Exports. MODULARIZE muss für ES6-Exporte aktiviert sein und wird implizit aktiviert, wenn nicht bereits gesetzt.

Dies wird implizit aktiviert, wenn das Ausgabesuffix auf 'mjs' gesetzt ist.

Standardwert: false

USE_ES6_IMPORT_META

Verwendet die ES6-Modul-Relative-Import-Funktion 'import.meta.url', um den WASM-Modulpfad automatisch zu erkennen. Diese wird möglicherweise von alten Browsern / Toolchains nicht unterstützt. Diese Einstellung darf nicht deaktiviert werden, wenn Node.js als Zielplattform (-sENVIRONMENT=*node*) gewählt ist.

Standardwert: true

EXPORT_NAME

Globale Variable, unter der das Modul für Umgebungen ohne standardisiertes Modul-Ladesystem (z.B. der Browser und die SM-Shell) exportiert wird.

Standardwert: 'Module'

DYNAMIC_EXECUTION

Wenn auf 0 gesetzt, geben wir eval() und new Function() nicht aus, was einige Funktionalitäten deaktiviert (was zu Laufzeitfehlern führt, wenn versucht wird, diese zu verwenden), aber es dem ausgegebenen Code ermöglicht, an Stellen akzeptabel zu sein, die die dynamische Codeausführung nicht zulassen (Chrome-Paket-App, privilegierte Firefox-App usw.). Übergeben Sie dieses Flag, wenn Sie eine Emscripten-Anwendung entwickeln, die auf eine privilegierte oder zertifizierte Ausführungsumgebung abzielt. Details finden Sie auf der Firefox Content Security Policy (CSP)-Webseite: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src, insbesondere die Richtlinien 'unsafe-eval' und 'wasm-unsafe-eval'.

Wenn dieses Flag gesetzt ist, sind die folgenden Funktionen (Linker-Flags) nicht verfügbar

• RELOCATABLE: Die Funktion loadDynamicLibrary müsste eval() aufrufen.

und einige Funktionen können auf langsamere Codepfade zurückfallen, wenn sie es benötigen: Embind: verwendet eval(), um Funktionen für die Geschwindigkeit zu jittern.

Zusätzlich sind die folgenden Emscripten-Laufzeitfunktionen nicht verfügbar, wenn DYNAMIC_EXECUTION=0 gesetzt ist, und ein Versuch, sie aufzurufen, löst eine Ausnahme aus

• emscripten_run_script(),

• emscripten_run_script_int(),

• emscripten_run_script_string(),

• dlopen(),

• Die Funktionen ccall() und cwrap() sind weiterhin verfügbar, aber sie sind darauf beschränkt, nur Funktionen aufrufen zu können, die zuvor im Module-Objekt exportiert wurden.

Wenn -sDYNAMIC_EXECUTION=2 gesetzt ist, werden Versuche, eval() aufzurufen, als Warnungen statt als Ausnahme ausgegeben.

Standardwert: 1

BOOTSTRAPPING_STRUCT_INFO

ob wir uns in der Bootstrapping-Phase zur Generierung von struct_info befinden

Standardwert: false

EMSCRIPTEN_TRACING

Einige Aufrufe zu Emscripten-Tracing-APIs hinzufügen

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_GLFW

Gibt die GLFW-Version an, gegen die gelinkt wird. Nur relevant, wenn Sie gegen die GLFW-Bibliothek linken. Gültige Optionen sind 2 für GLFW2 und 3 für GLFW3.

Standardwert: 0

WASM

Ob der Code in WebAssembly kompiliert werden soll. Setzen Sie dies auf 0, um stattdessen in JS statt in wasm zu kompilieren.

Geben Sie -sWASM=2 an, um gleichzeitig WebAssembly und JavaScript anzusprechen. In diesem Build-Modus werden zwei Dateien, a.wasm und a.wasm.js, erzeugt, und zur Laufzeit wird die WebAssembly-Datei geladen, wenn der Browser/die Shell dies unterstützt. Andernfalls wird der .wasm.js-Fallback verwendet.

Wenn WASM=2 aktiviert ist und der Browser das WebAssembly-Modul nicht kompilieren kann, wird die Seite im Wasm2JS-Modus neu geladen.

Standardwert: 1

STANDALONE_WASM

STANDALONE_WASM zeigt an, dass wir eine wasm-Datei ausgeben möchten, die ohne JavaScript ausgeführt werden kann. Die Datei wird dabei so weit wie möglich Standard-APIs wie wasi verwenden.

Diese Option garantiert nicht, dass das wasm alleine verwendet werden kann – wenn Sie APIs ohne nicht-JS-Alternative verwenden, werden wir diese weiterhin verwenden (z. B. OpenGL zum Zeitpunkt des Schreibens). Dies gibt Ihnen die Möglichkeit zu sehen, welche APIs fehlen, und wenn Sie für eine benutzerdefinierte wasi-Einbettung kompilieren, diese Ihrer Einbettung hinzuzufügen.

Wir können mit diesem Flag immer noch JS ausgeben, aber das JS sollte nur ein bequemer Weg sein, das wasm im Web oder in Node.js auszuführen, und Sie können das wasm ohne dieses JS alleine ausführen (wiederum, es sei denn, Sie verwenden APIs, für die es keine nicht-JS-Alternative gibt) in einer wasm-Laufzeitumgebung wie wasmer oder wasmtime.

Beachten Sie, dass wir auch ohne diese Option versuchen, wasi etc. Syscalls so weit wie möglich zu verwenden. Was diese Option ändert, ist, dass wir dies auch tun, wenn es einen Kompromiss bei der JS-Größe bedeutet. Wenn diese Option gesetzt ist, importieren wir zum Beispiel den Speicher nicht – der Import ist für JS nützlich, damit JS ihn verwenden kann, bevor das wasm überhaupt geladen wird, aber in wasi und anderen wasm-only-Umgebungen wird erwartet, dass der Speicher im wasm selbst erstellt wird. Dies verhindert einige mögliche JS-Optimierungen, daher tun wir dies nur hinter diesem Flag.

Wenn dieses Flag gesetzt ist, legalisieren wir die JS-Schnittstelle nicht, da das wasm in einer wasm-VM laufen soll, die i64s direkt verarbeiten kann. Würden wir es legalisieren, würde die wasm-VM die API nicht erkennen. Dies bedeutet jedoch, dass das optional ausgegebene JS nicht läuft, wenn Sie eine JS-API mit einem i64 verwenden. Sie können die WASM_BIGINT-Option verwenden, um dieses Problem zu vermeiden, indem Sie BigInts für i64s verwenden, was bedeutet, dass wir für JS nicht legalisieren müssen (dies erfordert jedoch eine ausreichend neue JS-VM).

Standardmäßig erfordern eigenständige Builds einen main-Einstiegspunkt. Wenn Sie stattdessen eine Bibliothek (auch bekannt als Reaktor) erstellen möchten, können Sie --no-entry übergeben.

Standardwert: false

BINARYEN_IGNORE_IMPLICIT_TRAPS

Ob implizite Traps bei der Optimierung in Binaryen ignoriert werden sollen. Implizite Traps sind die Traps, die bei einem Ladevorgang außerhalb der Grenzen oder einer Division/Rest von 0 usw. auftreten. Wenn diese Option gesetzt ist, nimmt der Optimierer an, dass Ladevorgänge keine Traps auslösen können und daher keinerlei Nebenwirkungen haben. Dies ist im Allgemeinen nicht sicher, da ein Ladevorgang hinter einer Bedingung stehen kann, die seine Sicherheit gewährleistet; aber wenn angenommen wird, dass der Ladevorgang keine Nebenwirkungen hat, könnte er bedingungslos ausgeführt werden. Aus diesem Grund ist diese Option im Allgemeinen bei großen und komplexen Projekten nicht nützlich, kann aber in einer kleinen und ausreichend einfachen Codebasis dazu beitragen, die Code-Größe etwas zu reduzieren.

Standardwert: false

BINARYEN_EXTRA_PASSES

Eine kommagetrennte Liste zusätzlicher Durchläufe, die im Binaryen-Optimierer ausgeführt werden sollen. Das Setzen dieser Option überschreibt/ersetzt die Standarddurchläufe nicht. Sie wird am Ende der Liste der Durchläufe angehängt.

Standardwert: “”

WASM_ASYNC_COMPILATION

Ob das wasm asynchron kompiliert werden soll, was effizienter ist und den Hauptthread nicht blockiert. Dies ist derzeit für alle außer den kleinsten Modulen erforderlich, um in Chrome zu laufen.

(Diese Option wurde früher BINARYEN_ASYNC_COMPILATION genannt)

Standardwert: true

DYNCALLS

Wenn auf 1 gesetzt, wird die dynCall() und dynCall_sig() API dem Aufrufer zur Verfügung gestellt.

Standardwert: false

WASM_BIGINT

WebAssembly-Integration mit JavaScript BigInt. Wenn aktiviert, müssen wir i64s nicht in Paare von i32s legalisieren, da die wasm-VM ein BigInt verwendet, wo ein i64 verwendet wird. Wenn WASM_BIGINT vorhanden ist, werden die standardmäßigen unterstützten Mindestbrowserversionen auf die Mindestversion erhöht, die BigInt unterstützt.

Standardwert: false

EMIT_PRODUCERS_SECTION

WebAssembly definiert eine „Producers Section“, in der sich Compiler und Tools selbst annotieren können, und LLVM gibt dies standardmäßig aus. Emscripten wird dies entfernen, so dass es nicht ausgegeben wird, da es die Code-Größe erhöht, und einige Benutzer möchten möglicherweise aus Datenschutz- oder Sicherheitsgründen keine Informationen über ihre Tools in ihren Builds haben, siehe https://github.com/WebAssembly/tool-conventions/issues/93.

Standardwert: false

EMIT_EMSCRIPTEN_LICENSE

Gibt Emscripten-Lizenzinformationen in der JS-Ausgabe aus.

Standardwert: false

LEGALIZE_JS_FFI

Ob die JS FFI-Schnittstellen (Imports/Exports) legalisiert werden sollen, indem sie umwickelt werden, um i64 automatisch auf i32 herabzustufen und f32 auf f64 hochzustufen. Dies ist notwendig, um mit JavaScript zu interagieren. Für Nicht-Web/Nicht-JS-Einbettungen kann es wünschenswert sein, dies auf 0 zu setzen.

Hinweis

Diese Einstellung ist veraltet

Standardwert: true

USE_SDL

Gibt die SDL-Version an, gegen die gelinkt wird. 1, der Standardwert, ist 1.3, das in JS implementiert ist. 2 ist ein Port des SDL C-Codes auf emscripten-ports. Wenn AUTO_JS_LIBRARIES auf 0 gesetzt ist, ist der Standardwert 0 und SDL wird nicht gelinkt. Alternative Syntax für die Verwendung des Ports: –use-port=sdl2

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: 0

USE_SDL_GFX

Gibt die SDL_gfx-Version an, gegen die gelinkt wird. Muss mit USE_SDL übereinstimmen

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: 0

USE_SDL_IMAGE

Gibt die SDL_image-Version an, gegen die gelinkt wird. Muss mit USE_SDL übereinstimmen.

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: 1

USE_SDL_TTF

Gibt die SDL_ttf-Version an, gegen die gelinkt wird. Muss mit USE_SDL übereinstimmen.

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: 1

USE_SDL_NET

Gibt die SDL_net-Version an, gegen die gelinkt wird. Muss mit USE_SDL übereinstimmen.

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: 1

USE_ICU

1 = ICU aus emscripten-ports verwenden. Alternative Syntax: –use-port=icu

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_ZLIB

1 = Zlib aus emscripten-ports verwenden. Alternative Syntax: –use-port=zlib

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_BZIP2

1 = bzip2 aus emscripten-ports verwenden. Alternative Syntax: –use-port=bzip2

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_GIFLIB

1 = giflib aus emscripten-ports verwenden. Alternative Syntax: –use-port=giflib

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_LIBJPEG

1 = libjpeg aus emscripten-ports verwenden. Alternative Syntax: –use-port=libjpeg

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_LIBPNG

1 = libpng aus emscripten-ports verwenden. Alternative Syntax: –use-port=libpng

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_REGAL

1 = Regal aus emscripten-ports verwenden. Alternative Syntax: –use-port=regal

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_BOOST_HEADERS

1 = Boost-Header aus emscripten-ports verwenden. Alternative Syntax: –use-port=boost_headers

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_BULLET

1 = bullet aus emscripten-ports verwenden. Alternative Syntax: –use-port=bullet

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_VORBIS

1 = vorbis aus emscripten-ports verwenden. Alternative Syntax: –use-port=vorbis

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_OGG

1 = ogg aus emscripten-ports verwenden. Alternative Syntax: –use-port=ogg

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_MPG123

1 = mpg123 aus emscripten-ports verwenden. Alternative Syntax: –use-port=mpg123

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_FREETYPE

1 = freetype aus emscripten-ports verwenden. Alternative Syntax: –use-port=freetype

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_SDL_MIXER

Gibt die SDL_mixer-Version an, gegen die gelinkt wird. Muss nicht unbedingt mit USE_SDL übereinstimmen, ist aber eine gute Idee.

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: 1

USE_HARFBUZZ

1 = Harfbuzz von Harfbuzz upstream verwenden. Alternative Syntax: –use-port=harfbuzz

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

USE_COCOS2D

3 = cocos2d v3 aus emscripten-ports verwenden. Alternative Syntax: –use-port=cocos2d

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: 0

USE_MODPLUG

1 = libmodplug aus emscripten-ports verwenden. Alternative Syntax: –use-port=libmodplug

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

SDL2_IMAGE_FORMATS

Formate, die in SDL2_image unterstützt werden sollen. Gültige Werte: bmp, gif, lbm, pcx, png, pnm, tga, xcf, xpm, xv

Standardwert: []

SDL2_MIXER_FORMATS

Formate, die in SDL2_mixer unterstützt werden sollen. Gültige Werte: ogg, mp3, mod, mid

Standardwert: [„ogg“]

USE_SQLITE3

1 = sqlite3 aus emscripten-ports verwenden. Alternative Syntax: –use-port=sqlite3

Hinweis

Anwendbar sowohl beim Linken als auch beim Kompilieren

Standardwert: false

SHARED_MEMORY

Wenn 1, zielt es auf die Kompilierung eines gemeinsamen Wasm-Speichers ab. [kompilieren+linken] – betrifft Benutzercode beim Kompilieren und Systembibliotheken beim Linken.

Standardwert: false

WASM_WORKERS

Wenn auf 1 gesetzt, wird die Unterstützung für Wasm Worker aktiviert. Wasm Worker ermöglichen Anwendungen, Threads mithilfe einer leichtgewichtigen, webspezifischen API zu erstellen, die auf der Wasm SharedArrayBuffer + Atomics API aufbaut. Wenn aktiviert, wird eine neue Build-Ausgabedatei a.ww.js generiert, um die Wasm Worker JS-Kontexte zu bootstrappen. Wenn auf 2 gesetzt, wird die Unterstützung für Wasm Worker aktiviert, jedoch ohne eine separate a.ww.js-Datei. Dies kann die Bereitstellung von Builds vereinfachen, hat aber den Nachteil, dass der generierte Build nicht mehr CSP-Eval-konform ist. [kompilieren+linken] – betrifft Benutzercode beim Kompilieren und Systembibliotheken beim Linken.

Standardwert: 0

AUDIO_WORKLET

Wenn wahr, aktiviert es die Zielausrichtung auf Wasm Web Audio AudioWorklets. Die vollständige Dokumentation finden Sie unter site/source/docs/api_reference/wasm_audio_worklets.rst

Standardwert: 0

WEBAUDIO_DEBUG

Wenn wahr, aktiviert es tiefgreifendes Debugging des Web Audio Backends.

Standardwert: 0

PTHREAD_POOL_SIZE

In Webbrowsern können Worker nicht erstellt werden, während der Hauptbrowser-Thread JS/Wasm-Code ausführt, aber der Hauptthread muss regelmäßig zur Browser-Ereignisschleife zurückkehren, damit die Worker-Initialisierung erfolgen kann. Dies bedeutet, dass pthread_create() im Wesentlichen ein asynchroner Vorgang ist, wenn er vom Hauptbrowser-Thread aufgerufen wird, und der Hauptthread muss wiederholt zur JS-Ereignisschleife zurückkehren, damit der Thread tatsächlich startet. Wenn Ihre Anwendung neue Threads synchron erstellen können muss, können Sie einen Pthread-Pool vorab erstellen, indem Sie -sPTHREAD_POOL_SIZE=x angeben. In diesem Fall wird die angegebene Anzahl von Workern vor dem Start der Anwendung in einen Pool vorgeladen, und so viele Threads stehen dann für die synchrone Erstellung zur Verfügung. Beachten Sie, dass diese Einstellung ein String ist und im JS-Code (direkt, ohne zusätzliche Anführungszeichen) ausgegeben wird, so dass, wenn Sie sie auf '5' setzen, 5 Worker im Pool verwendet werden, und so weiter. Der Vorteil, dass dies ein String ist, besteht darin, dass Sie ihn auf etwas wie 'navigator.hardwareConcurrency' setzen können (was die Anzahl der vom Browser gemeldeten Kerne verwendet und wie Sie genau genügend Worker für einen Threadpool erhalten, der der Anzahl der Kerne entspricht). [link] - betrifft den generierten JS-Laufzeitcode zur Linkzeit

Standardwert: 0

PTHREAD_POOL_SIZE_STRICT

Normalerweise können Anwendungen neue Threads erstellen, auch wenn der Pool leer ist. Wenn die Anwendung zur JS-Ereignisschleife zurückkehrt, bevor versucht wird, den Thread über pthread_join oder ein anderes blockierendes Primitiv zu blockieren, wird ein zusätzlicher Worker erstellt und der Thread-Callback ausgeführt. Das Zurückkehren zur Ereignisschleife erfordert jedoch benutzerdefinierte Änderungen am Code, um ihn an das Web anzupassen, und funktioniert nicht bei Standardanwendungen. Diese Anwendungen ohne Änderungen geraten höchstwahrscheinlich in einen Deadlock. Diese Einstellung stellt sicher, dass sie anstatt eines drohenden Deadlocks einen Laufzeitfehler EAGAIN erhalten, der zumindest von der C-/C++-Seite elegant behandelt werden kann. Werte

• 0 - Warnungen bei Erschöpfung des Thread-Pools deaktivieren

• 1 - Warnungen bei Erschöpfung des Thread-Pools aktivieren (Standard)

• 2 - Erschöpfung des Thread-Pools zu einem schwerwiegenden Fehler machen

Standardwert: 1

PTHREAD_POOL_DELAY_LOAD

Wenn Ihre Anwendung nicht die Möglichkeit benötigt, Threads synchron zu erstellen, aber dennoch die anfängliche Thread-Startzeit durch das Vorwärmen eines Worker-Pools opportunistisch beschleunigen möchte, können Sie die Größe des Pools mit -sPTHREAD_POOL_SIZE=x angeben und zusätzlich -sPTHREAD_POOL_DELAY_LOAD, wodurch die Laufzeit beim Start nicht darauf wartet, dass der Worker-Pool vollständig geladen ist. Stattdessen startet die Laufzeit sofort, und der Worker-Pool wird asynchron parallel im Hintergrund hochgefahren. Dies kann die Zeit verkürzen, die pthread_create()-Aufrufe benötigen, um tatsächlich einen Thread zu starten, ohne jedoch die Startgeschwindigkeit der Hauptanwendung zu verlangsamen. Wenn PTHREAD_POOL_DELAY_LOAD=0 (Standard), wartet die Laufzeit, bis der Pool gestartet ist, bevor main() ausgeführt wird. Wenn Sie synchron auf die erstellten Threads warten müssen (z. B. über pthread_join), müssen Sie auf das Module.pthreadPoolReady-Promise warten, bevor Sie dies tun, da Sie sonst sehr wahrscheinlich in Deadlocks geraten. [link] - betrifft den generierten JS-Laufzeitcode zur Linkzeit

Standardwert: false

DEFAULT_PTHREAD_STACK_SIZE

Standard-Stack-Größe, die für neu erstellte pthreads verwendet wird. Wenn nicht gesetzt, ist der Standardwert STACK_SIZE (der wiederum 64k ist). Kann auch zur Laufzeit mit pthread_attr_setstacksize() gesetzt werden. Beachten Sie, dass der Wasm-Kontrollfluss-Stack von diesem Stack getrennt ist. Dieser Stack enthält nur bestimmte lokale Funktionsvariablen, wie solche, deren Adressen genommen werden, oder solche, die zu groß sind, um als lokale Variablen im Wasm-Code zu passen.

Standardwert: 0

PTHREADS_PROFILING

Wahr, wenn mit –threadprofiler gebaut wird

Standardwert: false

ALLOW_BLOCKING_ON_MAIN_THREAD

Es ist gefährlich, pthread_join oder pthread_cond_wait im Hauptthread aufzurufen, da dies im Web zu Deadlocks führen kann (und es funktioniert auch mit einem Busy-Wait, was teuer ist). Siehe https://emscripten.de/docs/porting/pthreads.html#blocking-on-the-main-browser-thread Dies könnte in Zukunft standardmäßig auf 0 gesetzt werden; vorerst wird dies nur in der Konsole gewarnt.

Standardwert: true

PTHREADS_DEBUG

Wenn wahr, Debug-Traces für die Diagnose von pthreads-bezogenen Problemen hinzufügen.

Standardwert: false

EVAL_CTORS

Dies versucht, Code zur Kompilierungszeit auszuwerten. Der Hauptanwendungsfall ist die Auswertung globaler Ctor-Funktionen, also jener, die vor main() ausgeführt werden, aber main() selbst oder Teile davon können ebenfalls ausgewertet werden. Das Auswerten von Code auf diese Weise kann Laufzeitarbeit vermeiden, da es die Ergebnisse der Ausführung auf Speicher und Globals usw. anwendet, das Wasm „snapshotet“ und es dann einfach von dort aus ausführt, wenn es geladen wird.

Dies stoppt, wenn es etwas sieht, das es zur Kompilierzeit nicht evaluieren kann, wie z.B. einen Aufruf an einen Import. Wenn Sie mit dieser Option arbeiten, sehen Sie Protokolle, die anzeigen, was evaluiert wird und wo es stoppt.

Diese Optimierung kann die Code-Größe entweder reduzieren oder erhöhen. Wenn beispielsweise eine kleine Menge Code viele Speicheränderungen erzeugt, kann die Gesamtgröße zunehmen.

LLVMs GlobalOpt führt diese Operation fast aus. Es tut dies in einfachen Fällen, wo LLVM IR nicht zu komplex für seine Logik ist, um es zu evaluieren, aber es ist nicht mächtig genug für z.B. libc++ iostream ctors. Es ist einfach schwierig auf LLVM IR-Ebene – LLVM IR ist komplex und wird immer komplexer, daher würde dies erfordern, dass GlobalOpt einen vollständigen Interpreter hat, plus eine Möglichkeit, in LLVM IR globale Objekte zurückzuschreiben. Auf der Wasm-Ebene wurde jedoch alles auf ein einfaches niedriges Niveau reduziert, und wir müssen auch nur Bytes in ein Array schreiben, so dass dies für uns einfach ist. Ein weiteres Problem für LLVM ist, dass es nicht weiß, dass wir keinen weiteren Code verlinken werden, so dass es nur versucht, ctors mit geringster Priorität zu optimieren (während wir explizit wissen, ob dynamisches Linken aktiviert ist oder nicht).

Wenn auf den Wert 2 gesetzt, macht dies auch einige „unsichere“ Annahmen, insbesondere dass keine Eingaben empfangen werden, während ctors ausgewertet werden. Das bedeutet, dass wir Argumente für main() ignorieren und davon ausgehen, dass keine Umgebungsvariablen lesbar sind. Dies ermöglicht die Optimierung von mehr Programmen, aber Sie müssen sicherstellen, dass Ihr Programm nicht von diesen Funktionen abhängt – selbst das bloße Überprüfen des Wertes von argc kann zu Problemen führen.

Standardwert: 0

TEXTDECODER

Ist aktiviert, verwenden Sie die JavaScript TextDecoder API für die String-Marshalling. Standardmäßig aktiviert, setzen Sie dies auf 0, um es zu deaktivieren. Wenn auf 2 gesetzt, gehen wir davon aus, dass TextDecoder vorhanden und verwendbar ist, und geben keinen JS-Code aus, um darauf zurückzufallen, wenn es fehlt. In einthreadigen -Oz Build-Modi ist TEXTDECODER standardmäßig auf Wert == 2 gesetzt, um die Code-Größe zu sparen.

Standardwert: 1

EMBIND_STD_STRING_IS_UTF8

Embind-spezifisch: Wenn aktiviert, UTF-8-kodierte Daten in std::string-Bindung annehmen. Deaktivieren Sie dies, um binäre Datenübertragung zu unterstützen.

Standardwert: true

EMBIND_AOT

Embind-spezifisch: Wenn aktiviert, werden die Embind JavaScript Invoker-Funktionen zur Kompilierzeit generiert und in die JS-Ausgabedatei aufgenommen. In Verbindung mit DYNAMIC_EXECUTION=0 ermöglicht dies, dass exportierte Bindungen genauso schnell sind wie im DYNAMIC_EXECUTION=1-Modus, aber ohne die Notwendigkeit von eval(). Bei vielen Bindungen kann die JS-Ausgabegröße jedoch größer sein.

Standardwert: false

OFFSCREENCANVAS_SUPPORT

Wenn auf 1 gesetzt, wird die Unterstützung für die Übertragung von Canvas-Elementen an Pthreads und die Erstellung von WebGL-Kontexten darin aktiviert, sowie die explizite Swap-Steuerung für GL-Kontexte. Dies erfordert Browser-Unterstützung für die OffscreenCanvas-Spezifikation.

Standardwert: false

OFFSCREENCANVASES_TO_PTHREAD

Wenn Sie PROXY_TO_PTHREAD mit OFFSCREENCANVAS_SUPPORT verwenden, geben Sie hier eine kommagetrennte Liste von CSS-ID-Selektoren für Canvas-Elemente an, die beim Programmstart an den Pthread weitergeleitet werden sollen, z. B. '#canvas1, #canvas2'.

Standardwert: „#canvas“

OFFSCREEN_FRAMEBUFFER

Wenn auf 1 gesetzt, aktiviert es die Unterstützung für WebGL-Kontexte, um auf ein Offscreen-Render-Target zu rendern, um das implizite Swap-Verhalten von WebGL zu vermeiden, bei dem das Verlassen jedes Event-Callbacks automatisch einen „Flip“ durchführen würde, um gerenderte Inhalte auf dem Bildschirm anzuzeigen. Wenn ein Emscripten GL-Kontext mit Offscreen Framebuffer aktiviert ist, kann ein einzelner Frame aus mehreren Event-Callbacks zusammengesetzt werden, und die Swap-Funktion emscripten_webgl_commit_frame() wird dann explizit aufgerufen, um die gerenderten Inhalte auf dem Bildschirm anzuzeigen.

Die OffscreenCanvas-Funktion ermöglicht auch die explizite GL-Frame-Swapping-Unterstützung, und die -sOFFSCREEN_FRAMEBUFFER-Funktion kann verwendet werden, um die Unterstützung für den Zugriff auf WebGL in mehreren Threads bei fehlender OffscreenCanvas-Unterstützung im Browser zu polyfillen, auf Kosten von etwas Leistung und Latenz. OffscreenCanvas und Offscreen Framebuffer-Unterstützung können gleichzeitig aktiviert werden und ermöglichen es, OffscreenCanvas dort zu nutzen, wo es verfügbar ist, und andernfalls auf Offscreen Framebuffer zurückzugreifen.

Standardwert: false

FETCH_SUPPORT_INDEXEDDB

Wenn ungleich Null, unterstützt die Fetch API das Backing in IndexedDB. Wenn 0, wird IndexedDB nicht verwendet. Auf 0 setzen, wenn IndexedDB-Unterstützung für die Zielanwendung nicht interessant ist, um ein paar kBytes zu sparen.

Standardwert: true

FETCH_DEBUG

Wenn ungleich Null, gibt Debugging-Informationen in library_fetch.js aus

Standardwert: false

FETCH

Wenn ungleich Null, aktiviert die emscripten_fetch API.

Standardwert: false

WASMFS

ACHTUNG [WIP]: Experimentelle Funktion. Bitte auf eigene Gefahr verwenden. Dies wird die aktuelle JS-Dateisystemimplementierung eventuell ersetzen. Wenn auf 1 gesetzt, wird die neue Dateisystemimplementierung verwendet.

Hinweis

Dies ist eine experimentelle Einstellung

Standardwert: false

SINGLE_FILE

Wenn auf 1 gesetzt, werden alle Unterressourcen in der ausgegebenen Datei als Base64-Stringliterale eingebettet. Eingebettete Unterressourcen können (sind aber nicht beschränkt auf) wasm, asm.js und statischen Speicherinitialisierungscode umfassen.

Bei der Verwendung von Code, der von dieser Option abhängt, muss Ihre Content Security Policy möglicherweise aktualisiert werden. Insbesondere erfordert das Einbetten von asm.js, dass die `script-src`-Direktive `'unsafe-inline'` zulässt, und die Verwendung eines Workers erfordert, dass die `child-src`-Direktive `blob:` zulässt. Wenn Sie keine Content Security Policy verwenden oder Ihr CSP-Header weder `script-src` noch `child-src` enthält, können Sie diese Warnung sicher ignorieren.

Standardwert: false

AUTO_JS_LIBRARIES

Wenn auf 1 gesetzt, sind alle JS-Bibliotheken zur Linkzeit automatisch verfügbar. Dies wird im STRICT-Modus (oder mit MINIMAL_RUNTIME) auf 0 gesetzt, was bedeutet, dass Sie explizit -lfoo.js zur Linkzeit angeben müssen, um auf Bibliotheksfunktionen in library_foo.js zugreifen zu können.

Standardwert: true

AUTO_NATIVE_LIBRARIES

Wie AUTO_JS_LIBRARIES, aber für native Bibliotheken wie libgl, libal und libhtml5. Wenn dies deaktiviert ist, ist es notwendig, explizit z.B. -lhtml5 hinzuzufügen und die Bibliothek zuerst mit embuilder zu erstellen.

Standardwert: true

MIN_FIREFOX_VERSION

Gibt die älteste Hauptversion von Firefox an, die angesprochen werden soll. D.h. alle Firefox-Versionen >= MIN_FIREFOX_VERSION sollen funktionieren. Übergeben Sie -sMIN_FIREFOX_VERSION=majorVersion, um die Unterstützung für Firefox-Versionen älter als < majorVersion einzustellen. Firefox 79 wurde am 28.07.2020 veröffentlicht. MAX_INT (0x7FFFFFFF oder -1) gibt an, dass das Ziel nicht unterstützt wird. Der minimale unterstützte Wert ist 34, der am 01.12.2014 veröffentlicht wurde.

Standardwert: 79

MIN_SAFARI_VERSION

Gibt die älteste Version von Desktop Safari an, die angesprochen werden soll. Die Version wird in MMmmVV kodiert, z.B. 70101 bezeichnet Safari 7.1.1. Safari 14.1.0 wurde am 26. April 2021 veröffentlicht, gebündelt mit macOS 11.0 Big Sur und iOS 14.5. Der vorherige Standard, Safari 12.0.0, wurde am 17. September 2018 veröffentlicht, gebündelt mit macOS 10.14.0 Mojave. HINWEIS: Emscripten kann keinen Code erzeugen, der in iOS 9.3.5 und älter funktioniert, d.h. iPhone 4s, iPad 2, iPad 3, iPad Mini 1, Pod Touch 5 und älter, siehe https://github.com/emscripten-core/emscripten/pull/7191. MAX_INT (0x7FFFFFFF oder -1) gibt an, dass das Ziel nicht unterstützt wird. Der minimale unterstützte Wert ist 90000, der 2015 veröffentlicht wurde.

Standardwert: 140100

MIN_CHROME_VERSION

Gibt die älteste Version von Chrome an. Z.B. -sMIN_CHROME_VERSION=58 übergeben, um die Unterstützung für Chrome 57 und älter einzustellen. Diese Einstellung gilt auch für modernes Chromium-basiertes Edge, das Versionsnummern mit Chrome teilt. Chrome 85 wurde am 25.08.2020 veröffentlicht. MAX_INT (0x7FFFFFFF oder -1) gibt an, dass das Ziel nicht unterstützt wird. Der minimal unterstützte Wert ist 32, der am 04.01.2014 veröffentlicht wurde.

Standardwert: 85

MIN_NODE_VERSION

Gibt die minimale Node-Version an, auf die der generierte Code abzielt. Diese unterscheidet sich von der minimalen Version, die zum Ausführen des Emscripten-Compilers erforderlich ist. Diese Version stimmt mit dem aktuellen Ubuntu TLS 20.04 (Focal) überein. Die Version wird in MMmmVV kodiert, z.B. 181401 bezeichnet Node 18.14.01. Der minimal unterstützte Wert ist 101900, der am 05.02.2020 veröffentlicht wurde.

Standardwert: 160000

SUPPORT_ERRNO

Ob wir das Setzen von errno aus dem JS-Bibliothekscode unterstützen. In MINIMAL_RUNTIME-Builds ist diese Option standardmäßig auf 0 gesetzt.

Hinweis

Diese Einstellung ist veraltet

Standardwert: true

MINIMAL_RUNTIME

Wenn wahr, verwendet es eine minimale Laufzeit ohne POSIX-Funktionen, Module, preRun/preInit/etc., Emscripten-eingebaute XHR-Ladefunktion oder library_browser.js. Aktivieren Sie diese Einstellung, um die kleinstmögliche Code-Größe zu erreichen. Setzen Sie MINIMAL_RUNTIME=2, um noch mehr Code-Größenoptimierungen zu aktivieren. Diese Optimierungen sind ziemlich hacky und umgehen Einschränkungen in Closure und anderen Teilen des Build-Systems, daher funktionieren sie möglicherweise nicht in allen generierten Programmen (können aber für wirklich kleine Programme nützlich sein).

Standardmäßig werden keine Symbole auf dem Module-Objekt exportiert. Um lebendig gehaltene Symbole zu exportieren, verwenden Sie bitte -sEXPORT_KEEPALIVE=1.

Standardwert: 0

MINIMAL_RUNTIME_STREAMING_WASM_COMPILATION

Wenn auf 1 gesetzt, verwendet MINIMAL_RUNTIME die Streaming WebAssembly Kompilierung, bei der das WebAssembly-Modul bereits während des Downloads kompiliert wird. Damit dies funktioniert, MUSS der Webserver die .wasm-Datei ordnungsgemäß mit dem HTTP-Antwortheader „Content-Type: application/wasm“ bereitstellen. Wenn dieser HTTP-Header nicht vorhanden ist, schlägt z.B. Firefox 73 mit der Fehlermeldung TypeError: Response has unsupported MIME type fehl und Chrome 78 mit der Fehlermeldung Uncaught (in promise) TypeError: Failed to execute ‘compile’ on ‘WebAssembly’: Incorrect response MIME type. Expected ‘application/wasm’. Wenn auf 0 gesetzt (Standard), ist die Streaming WebAssembly Kompilierung deaktiviert, was bedeutet, dass das WebAssembly-Modul zuerst vollständig heruntergeladen wird und erst dann die Kompilierung beginnt. Für große .wasm-Module und Produktionsumgebungen sollte dies auf 1 gesetzt werden, um schnellere Startgeschwindigkeiten zu erzielen. Diese Einstellung ist jedoch standardmäßig deaktiviert, da sie eine serverseitige Konfiguration erfordert und bei wirklich kleinen Seiten kein merklicher Unterschied besteht (hat auch einen Einfluss von ca. 100 Byte auf die Code-Größe)

Standardwert: false

MINIMAL_RUNTIME_STREAMING_WASM_INSTANTIATION

Wenn auf 1 gesetzt, verwendet MINIMAL_RUNTIME die Streaming WebAssembly Instanziierung, bei der das WebAssembly-Modul bereits während des Downloads kompiliert und instanziiert wird. Es gelten die gleichen Einschränkungen/Anforderungen wie bei MINIMAL_RUNTIME_STREAMING_WASM_COMPILATION. MINIMAL_RUNTIME_STREAMING_WASM_COMPILATION und MINIMAL_RUNTIME_STREAMING_WASM_INSTANTIATION können nicht gleichzeitig aktiv sein. Welche der beiden schneller ist, hängt von der Größe des Wasm-Moduls, der Größe der JS-Laufzeitdatei, der Größe der vorab geladenen Datendatei und dem jeweiligen Browser ab.

Standardwert: false

SUPPORT_LONGJMP

Wenn auf „emscripten“ oder „wasm“ gesetzt, unterstützt der Compiler setjmp() und longjmp(). Wenn auf 0 gesetzt, sind diese APIs nicht verfügbar. Wenn Sie C++-Ausnahmen verwenden, aber die setjmp()+longjmp()-API nicht benötigen, können Sie dies auf 0 setzen, um etwas Code-Größe und Leistung beim Abfangen von Ausnahmen zu sparen.

„emscripten“: (Standard) Emscripten setjmp/longjmp-Handhabung mit JavaScript „wasm“: setjmp/longjmp-Handhabung mit Wasm EH-Anweisungen (experimentell)

• 0: Keine setjmp/longjmp-Behandlung

• 1: Standard-setjmp/longjmp-Behandlung, abhängig vom Ausnahmemodus. 'wasm', wenn '-fwasm-exception' verwendet wird, sonst 'emscripten'.

[kompilieren+linken] – zur Kompilierzeit aktiviert dies die für die longjmp-Unterstützung zur Codegenerierungszeit erforderlichen Transformationen, während es beim Linken die Einbindung der Bibliotheksunterstützung ermöglicht.

Standardwert: true

DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR

Wenn auf 1 gesetzt, deaktiviert dies das alte veraltete HTML5 API-Ereignisziel-Suchverhalten. Wenn aktiviert, gibt es kein „Module.canvas“-Objekt, keine magische „null“-Standardbehandlung, und DOM-Element-„target“-Parameter werden als CSS-Selektoren interpretiert, anstatt sich auf DOM-IDs zu beziehen.

Standardwert: true

HTML5_SUPPORT_DEFERRING_USER_SENSITIVE_REQUESTS

Bestimmte Browser-DOM-API-Operationen, wie das Anfordern des Vollbildmodus-Übergangs oder der Pointer-Sperre, erfordern, dass die Anforderung aus einem vom Benutzer initiierten Ereignis stammt, wie z.B. einem Mausklick oder Tastendruck. Die Umstrukturierung einer Anwendung, um dieser Art von Programmstruktur zu folgen, kann schwierig sein, daher ermöglicht HTML5_SUPPORT_DEFERRING_USER_SENSITIVE_REQUESTS eine transparente Emulation, indem solche Anforderungen verzögert werden, bis ein geeigneter Ereignis-Callback generiert wird. Setzen Sie dies auf 0, um die Unterstützung für die Verzögerung zu deaktivieren, um Code-Größe zu sparen, wenn Ihre Anwendung keine Unterstützung für verzögerte Aufrufe benötigt.

Standardwert: true

MINIFY_HTML

Gibt an, ob die generierte .html-Datei durch html-minifier läuft. Die von html-minifier ausgeführten Optimierungsdurchläufe hängen von den Debug- und Optimierungsstufen ab. Bei -g2 und höher wird keine Minifizierung durchgeführt. Bei -g1 wird minifiziert, aber Whitespace bleibt erhalten. Die Minifizierung erfordert mindestens -O1 oder -Os. Übergeben Sie -sMINIFY_HTML=0, um die HTML-Minifizierung explizit ganz zu deaktivieren.

Standardwert: true

MAYBE_WASM2JS

Ob wir wasm2js möglicherweise verwenden. Dies wird normalerweise nach wasm kompiliert, ermöglicht aber, wasm2js später auf das wasm anzuwenden, und Sie können wählen, ob Sie das normale wasm oder den wasm2js-Code ausführen möchten. Details dazu finden Sie im Test test_maybe_wasm2js. Diese Option kann für das Debugging und die Bisektion nützlich sein.

Standardwert: false

ASAN_SHADOW_SIZE

Diese Option wird nicht mehr verwendet. Die geeignete Shadow-Memory-Größe wird nun aus INITIAL_MEMORY und MAXIMUM_MEMORY berechnet. Wird in einer zukünftigen Version entfernt.

Standardwert: -1

USE_OFFSET_CONVERTER

Ob wir den Offset-Konverter verwenden sollen. Dies wird für ältere Versionen von v8 (<7.7) benötigt, die den Hex-Modul-Offset im Wasm-Binär in Stack-Traces nicht angeben, sowie um die Verwendung von Quellkarten-Einträgen über Funktionsgrenzen hinweg zu vermeiden.

Standardwert: false

LOAD_SOURCE_MAP

Ob wir die WASM-Source-Map zur Laufzeit laden sollen. Dies wird automatisch aktiviert, wenn -gsource-map mit Sanitizern verwendet wird.

Standardwert: false

DEFAULT_TO_CXX

Standardmäßig im C++-Modus, auch wenn als emcc anstatt emc++ ausgeführt. Wenn dies deaktiviert ist, ist em++ zum Linken von C++-Programmen erforderlich. Das Deaktivieren entspricht dem Verhalten von gcc/g++ und clang/clang++.

Standardwert: true

PRINTF_LONG_DOUBLE

Während LLVMs wasm32 long double = float128 hat, unterstützen wir standardmäßig nicht das Drucken dieser mit voller Präzision. Stattdessen drucken wir als 64-Bit-Doubles, was die Code-Größe der libc spart. Sie können diese Option aktivieren, um eine libc mit voller long double Druckpräzision zu erhalten.

Standardwert: false

SEPARATE_DWARF_URL

Das Setzen dieser Option beeinflusst den Pfad, der im wasm ausgegeben wird und sich auf die DWARF-Datei im Modus -gseparate-dwarf bezieht. Dies ermöglicht es, die Debugging-Datei an einem benutzerdefinierten Ort zu hosten.

Standardwert: ''

ERROR_ON_WASM_CHANGES_AFTER_LINK

Emscripten führt wasm-ld zum Linken aus und nimmt in einigen Fällen danach weitere Änderungen am wasm vor, z.B. das Ausführen von wasm-opt zur Optimierung des Binärs in optimierten Builds. In einigen Builds sind jedoch nach dem Linken keine wasm-Änderungen erforderlich. Dies kann den gesamten Link-Schritt beschleunigen und auch aus anderen Gründen wichtig sein, z.B. beim Debuggen, wenn das wasm nicht modifiziert wird, bleiben die DWARF-Informationen von LLVM erhalten (wasm-opt kann sie in einigen Fällen umschreiben, aber in anderen, wie split-dwarf, nicht). Wenn dieses Flag aktiviert ist, wird zur Linkzeit ein Fehler ausgegeben, wenn der Build nach dem Linken Änderungen am wasm erfordert. Dies kann z.B. beim Testen nützlich sein. Einige Beispiele für Funktionen, die Post-Link-Wasm-Änderungen erfordern, sind: - Herabstufung von i64 auf i32-Paare an der JS-Grenze (siehe WASM_BIGINT) - Herabstufung von Vorzeichenerweiterungsoperationen bei älteren Browsern.

Standardwert: false

ABORT_ON_WASM_EXCEPTIONS

Abbruch bei unbehandelten Ausnahmen, die beim Aufruf exportierter WebAssembly-Funktionen auftreten. Dies lässt das Programm sich eher wie ein natives Programm verhalten, bei dem das Betriebssystem den Prozess beenden würde und kein weiterer Code ausgeführt werden könnte, wenn eine unbehandelte Ausnahme (z.B. Speicherzugriff außerhalb der Grenzen) auftritt. Dies instrumentiert alle exportierten Funktionen, um geworfene Ausnahmen abzufangen und abort() aufzurufen, wenn sie auftreten. Sobald das Programm abbricht, schlagen alle exportierten Funktionsaufrufe mit einer „Programm wurde bereits abgebrochen“-Ausnahme fehl, um Aufrufe in Code mit einem potenziell beschädigten Programmzustand zu verhindern. Dies fügt eine geringe feste Menge zur Code-Größe in optimierten Builds hinzu und einen leichten Overhead für die zusätzliche instrumentierte Funktionsindirektion. Aktivieren Sie dies, wenn Sie möchten, dass Emscripten unbehandelte Ausnahmen elegant behandelt, auf Kosten weniger zusätzlicher Bytes. Ausnahmen, die innerhalb der main-Funktion auftreten, werden bereits über einen alternativen Mechanismus behandelt.

Standardwert: false

PURE_WASI

Erstellt Binärdateien, die so viele WASI-APIs wie möglich verwenden und zusätzliche JS-Unterstützungsbibliotheken für diese APIs enthalten. Dies ermöglicht Emscripten, Binärdateien zu erstellen, die WASI-konformer sind, und ermöglicht es auch, WASI-Binärdateien, die mit anderen SDKs (z.B. wasi-sdk) erstellt wurden, zu verarbeiten und auszuführen. Diese Einstellung ist experimentell und kann sich ändern oder entfernt werden. Impliziert STANDALONE_WASM.

Hinweis

Dies ist eine experimentelle Einstellung

Standardwert: false

IMPORTED_MEMORY

Auf 1 setzen, um das WebAssembly.Memory-Objekt außerhalb des Wasm-Moduls zu definieren. Standardmäßig definiert das Wasm-Modul den Speicher und exportiert ihn nach JavaScript. Die Verwendung der folgenden Einstellungen aktiviert diese Einstellung, da sie davon abhängen, den Speicher in JavaScript definieren zu können: - -pthread - RELOCATABLE - ASYNCIFY_LAZY_LOAD_CODE - WASM2JS (WASM=0)

Standardwert: false

SPLIT_MODULE

Code zum Laden geteilter Wasm-Module generieren. Diese Option generiert automatisch zwei Wasm-Dateien als Ausgabe, eine mit dem Suffix .orig und eine ohne. Die Standarddatei (ohne Suffix) generiert beim Ausführen Instrumentierungsdaten, die später in wasm-split (das binaryen-Tool) eingespeist werden können. Außerdem enthält der generierte JS-Code Hilfsfunktionen zum Laden geteilter Module.

Standardwert: false

AUTOLOAD_DYLIBS

Für MAIN_MODULE-Builds: Automatisch alle dynamischen Bibliotheksabhängigkeiten beim Start laden, bevor das Hauptmodul geladen wird.

Standardwert: true

ALLOW_UNIMPLEMENTED_SYSCALLS

Nicht implementierte JS-Syscalls in die endgültige Ausgabe aufnehmen. Dies ermöglicht die Kompilierung von Programmen, die zur Laufzeit von diesen Syscalls abhängen, auch wenn diese Syscalls zur Laufzeit fehlschlagen (oder nichts tun).

Standardwert: true

TRUSTED_TYPES

Aufrufe von Worker(…) und importScripts(…) als Trusted Types-kompatibel zulassen. Trusted Types ist eine Web-Plattformfunktion, die DOM-XSS durch Einschränkung der Verwendung von DOM-Sink-APIs mindern soll. Siehe https://w3c.github.io/webappsec-trusted-types/.

Standardwert: false

POLYFILL

Beim Targeting älterer Browser benötigt Emscripten manchmal, dass Polyfills in die Ausgabe aufgenommen werden. Wenn Sie das Polyfilling lieber selbst über einen anderen Mechanismus erledigen möchten, können Sie Emscripten daran hindern, diese zu generieren, indem Sie -sNO_POLYFILL oder -sPOLYFILL=0 übergeben. Bei Standard-Browser-Targets benötigt Emscripten keine Polyfills, daher ist diese Einstellung nur erforderlich, wenn auch explizit ältere Browser angesprochen werden.

Standardwert: true

RUNTIME_DEBUG

Wenn wahr, fügt es Tracing zu den Kernlaufzeitfunktionen hinzu. Diese Einstellung ist standardmäßig aktiviert, wenn eine der folgenden Debugging-Einstellungen aktiviert ist: - PTHREADS_DEBUG - DYLINK_DEBUG - LIBRARY_DEBUG - GL_DEBUG - OPENAL_DEBUG - EXCEPTION_DEBUG - SYSCALL_DEBUG - WEBSOCKET_DEBUG - SOCKET_DEBUG - FETCH_DEBUG

Standardwert: false

LEGACY_RUNTIME

Enthält JS-Bibliothekssymbole, die zuvor Teil der Standardlaufzeit waren. Ohne dies können solche Symbole verfügbar gemacht werden, indem sie zu DEFAULT_LIBRARY_FUNCS_TO_INCLUDE oder über die Abhängigkeiten eines anderen JS-Bibliothekssymbols hinzugefügt werden.

Standardwert: false

SIGNATURE_CONVERSIONS

Benutzerdefinierte Funktionen, die mit Signaturkonvertierung umwickelt werden sollen, die Zeigerargumente annehmen oder zurückgeben. Betrifft nur MEMORY64=1-Builds, Details siehe create_pointer_conversion_wrappers in emscripten.py. Verwenden Sie _ für Nicht-Zeiger-Argumente, p für Zeiger-/i53-Argumente und P für optionale Zeiger-/i53-Werte. Beispiel: -sSIGNATURE_CONVERSIONS=someFunction:_p,anotherFunction:p

Standardwert: []