Emscripten Compiler-Frontend (emcc)

Das Emscripten Compiler-Frontend (emcc) wird verwendet, um den Emscripten-Compiler über die Befehlszeile aufzurufen. Es ist im Grunde ein Drop-in-Ersatz für einen Standard-Compiler wie gcc oder clang.

Befehlszeilensyntax

emcc [options] file...

(Beachten Sie, dass Sie ./emcc benötigen, wenn Sie emcc aus Ihrem aktuellen Verzeichnis ausführen möchten.)

Die Eingabedatei(en) können entweder Quellcodedateien sein, die Clang verarbeiten kann (C oder C++), Objektdateien (erstellt von emcc -c), oder LLVM-Assembly-Dateien.

Argumente

Die meisten Clang-Optionen funktionieren, ebenso wie gcc-Optionen, zum Beispiel

# Display this information
emcc --help

# Display compiler version information
emcc --version

Um die vollständige Liste der von der von Emscripten verwendeten Clang-Version unterstützten Clang-Optionen anzuzeigen, führen Sie clang --help aus.

Optionen, die in emcc geändert oder neu sind, sind unten aufgeführt

-O0

[kompilieren+linken] Keine Optimierungen (Standard). Dies ist die empfohlene Einstellung, um ein Projekt zu portieren, da es verschiedene Zusicherungen enthält.

Diese und andere Optimierungseinstellungen sind sowohl beim Kompilieren als auch beim Linken sinnvoll. Beim Kompilieren beeinflussen sie LLVM-Optimierungen, und beim Linken beeinflussen sie die endgültige Optimierung des Codes in Binaryen sowie die Optimierung des JS. (Für schnelle inkrementelle Builds ist -O0 am besten, während Sie für die Veröffentlichung mit einer höheren Einstellung linken sollten.)

-O1

[kompilieren+linken] Einfache Optimierungen. Während des Kompilierungsschritts umfassen diese LLVM -O1 Optimierungen. Während des Linkschritts umfassen diese nicht verschiedene Laufzeit-Zusicherungen in JS, die -O0

-O2

[kompilieren+linken] Wie -O1, aber aktiviert mehr Optimierungen. Beim Linken werden auch verschiedene JavaScript-Optimierungen aktiviert.

Hinweis

Diese JavaScript-Optimierungen können die Code-Größe reduzieren, indem sie Dinge entfernen, die der Compiler nicht als verwendet ansieht, insbesondere Teile der Laufzeit können entfernt werden, wenn sie nicht im Module-Objekt exportiert werden. Der Compiler ist sich des Codes in –pre-js und –post-js bewusst, sodass Sie die Laufzeit dort sicher verwenden können. Alternativ können Sie EXPORTED_RUNTIME_METHODS verwenden, siehe src/settings.js.

-O3

[kompilieren+linken] Wie -O2, aber mit zusätzlichen Optimierungen, die länger dauern können.

Hinweis

Dies ist eine gute Einstellung für einen Release-Build.

-Og

[kompilieren+linken] Wie -O1. In zukünftigen Versionen könnte diese Option verschiedene Optimierungen deaktivieren, um die Debugbarkeit zu verbessern.

-Os

[kompilieren+linken] Wie -O3, konzentriert sich aber mehr auf die Code-Größe (und kann Kompromisse bei der Geschwindigkeit eingehen). Dies kann sowohl Wasm als auch JavaScript beeinflussen.

-Oz

[kompilieren+linken] Wie -Os, reduziert aber die Code-Größe noch weiter und kann länger dauern. Dies kann sowohl Wasm als auch JavaScript beeinflussen.

Hinweis

Weitere Tipps zur Optimierung Ihres Codes finden Sie unter Code optimieren.

-sOPTION[=WERT]

[verschiedene OPTIONEN wirken sich in verschiedenen Phasen aus, die meisten zur Linkzeit] Emscripten-Build-Optionen. Die verfügbaren Optionen finden Sie unter src/settings.js.

Hinweis

Wenn kein Wert angegeben ist, wird standardmäßig 1 verwendet.

Hinweis

Bei booleschen Optionen ist es möglich, das Präfix NO_ zu verwenden, um deren Bedeutung umzukehren. Zum Beispiel ist -sEXIT_RUNTIME=0 dasselbe wie -sNO_EXIT_RUNTIME=1 und umgekehrt. Dies wird in den meisten Fällen nicht empfohlen.

Hinweis

Listen können als kommagetrennte Zeichenfolgen angegeben werden

-sEXPORTED_FUNCTIONS=foo,bar

Hinweis

Wir unterstützen auch ältere Listenformate, die mehr Anführungszeichen beinhalten. Listen können mit oder ohne Anführungszeichen um jedes Element und mit oder ohne Klammern um die Liste angegeben werden. Zum Beispiel sind alle folgenden äquivalent

-sEXPORTED_FUNCTIONS="foo","bar"
-sEXPORTED_FUNCTIONS=["foo","bar"]
-sEXPORTED_FUNCTIONS=[foo,bar]

Hinweis

Für Listen, die Klammern oder Anführungszeichen enthalten, benötigen Sie in den meisten Shells Anführungszeichen ("), um Fehler zu vermeiden. Zwei Beispiele sind unten dargestellt

-sEXPORTED_FUNCTIONS="['liblib.so']"
-s"EXPORTED_FUNCTIONS=['liblib.so']"

Sie können auch angeben, dass der Wert einer Option aus einer Datei gelesen werden soll. Zum Beispiel wird das Folgende EXPORTED_FUNCTIONS basierend auf dem Inhalt der Datei unter **path/to/file** festlegen.

-sEXPORTED_FUNCTIONS=@/path/to/file

Hinweis

• In diesem Fall sollte die Datei eine Liste von Symbolen enthalten, eines pro Zeile. Für ältere Anwendungsfälle werden auch JSON-formatierte Dateien unterstützt: z.B. ["_func1", "func2"].

• Der angegebene Dateipfad muss absolut, nicht relativ sein.

• Die Datei kann Kommentare enthalten, deren erstes Zeichen der Zeile '#' ist.

Hinweis

Optionen können als einzelnes Argument mit oder ohne Leerzeichen zwischen dem -s und dem Optionsnamen angegeben werden. z.B. -sFOO oder -s FOO. Es wird dringend empfohlen, die Notation ohne Leerzeichen zu verwenden.

-g

[kompilieren+linken] Debug-Informationen beibehalten.

• Beim Kompilieren zu Objektdateien ist dies dasselbe wie in Clang und gcc, es fügt DWARF-Debug-Informationen zu den Objektdateien hinzu.

• Beim Linken ist dies äquivalent zu -g3.

-gseparate-dwarf[=DATEINAME]

[wie -g3, wenn zur Kompilierzeit übergeben, sonst zur Linkzeit angewendet] Debug-Informationen beibehalten, aber in einer separaten Datei. Dies ist dasselbe wie -g, aber die Hauptdatei enthält keine Debug-Informationen. Stattdessen sind die Debug-Informationen in einer separaten Datei vorhanden, in DATEINAME, falls angegeben, andernfalls dieselbe wie die Wasm-Datei, jedoch mit dem Suffix .debug.wasm. Während die Hauptdatei keine Debug-Informationen enthält, enthält sie eine URL, wo die Debug-Datei liegt, damit Entwicklungswerkzeuge sie finden können. Sie können -sSEPARATE_DWARF_URL=URL verwenden, um diesen Speicherort anzupassen (dies ist nützlich, wenn Sie sie beispielsweise auf einem anderen Server hosten möchten).

-gsplit-dwarf

Aktiviert Debug Fission, wodurch geteilte DWARF-Objektdateien neben den Wasm-Objektdateien erstellt werden. Diese Option muss zusammen mit -c verwendet werden.

-gsource-map

[link] Eine Source Map mit LLVM-Debug-Informationen generieren (die in Objektdateien vorhanden sein müssen, d.h. sie sollten mit -g kompiliert worden sein). Wenn diese Option angegeben ist, wird die **.wasm**-Datei aktualisiert, um einen sourceMappingURL-Abschnitt zu haben. Die resultierende URL hat das Format: <basis-url> + <wasm-dateiname> + .map. <basis-url> ist standardmäßig leer (was bedeutet, dass die Source Map aus demselben Verzeichnis wie die Wasm-Datei bereitgestellt wird). Sie kann mit –source-map-base geändert werden.

-g<level>

[kompilieren+linken] Steuert den Grad der Debugbarkeit. Jedes Level baut auf dem vorherigen auf

• -g0: Keine Anstrengungen unternehmen, um den Code debugbar zu halten.

• -g1: Beim Linken, Leerraum in JavaScript beibehalten.

• -g2: Beim Linken, Funktionsnamen im kompilierten Code beibehalten.

• -g3: Beim Kompilieren zu Objektdateien, Debug-Info beibehalten, einschließlich JS-Leerraum, Funktionsnamen und LLVM-Debug-Info (DWARF), falls vorhanden (dies ist dasselbe wie -g).

--profiling

[wie -g2, wenn zur Kompilierzeit übergeben, sonst zur Linkzeit angewendet] Vernünftige Standardeinstellungen verwenden, wenn JavaScript ausgegeben wird, um den Build lesbar zu machen, aber dennoch nützlich für die Profilerstellung. Dies setzt -g2 (Leerraum und Funktionsnamen beibehalten) und kann auch Optimierungen aktivieren, die die Leistung beeinflussen und sonst in -g2 möglicherweise nicht durchgeführt würden.

--profiling-funcs

[link] Funktionsnamen beim Profiling beibehalten, aber ansonsten Leerraum und Namen minimieren, wie wir es normalerweise in optimierten Builds tun. Dies ist nützlich, wenn Sie Profilergebnisse basierend auf Funktionsnamen betrachten möchten, aber den ausgegebenen Code nicht lesen möchten.

--tracing

[link] Aktivieren Sie die Emscripten Tracing API.

--reproduce=<datei.tar>

[kompilieren+linken] Tar-Datei mit Eingaben und Befehl zur Reproduktion des Aufrufs schreiben. Beim Teilen dieser Datei beachten Sie, dass sie alle Objektdateien, Quelldateien und Bibliotheken enthält, die an den Compiler übergeben wurden.

--emit-symbol-map

[link] Eine Map-Datei zwischen Funktionsindizes im Wasm und Funktionsnamen speichern. Durch das Speichern der Namen in einer separaten Datei können Sie den Versand der Namen vermeiden und dennoch aussagekräftige Stack-Traces rekonstruieren, indem Sie die Indizes wieder in die Namen übersetzen.

Hinweis

Bei Verwendung mit -sWASM=2 werden zwei Symboldateien erstellt. [Name].js.symbols (mit WASM-Symbolen) und [Name].wasm.js.symbols (mit ASM.js-Symbolen)

--emit-minification-map <datei>

[link] In Fällen, in denen Emscripten eine Import-/Exportminimierung durchführt, kann diese Option verwendet werden, um eine Datei auszugeben, die minimierte Namen auf ihre ursprünglichen Namen zurückführt. Das Format dieser Datei ist eine einzelne Zeile pro Import/Export in der Form <minimierterName>:<originalName>.

-flto

[kompilieren+linken] Aktiviert Link-Time-Optimierungen (LTO).

--closure 0|1|2

[link] Führt den Closure Compiler aus. Mögliche Werte sind

• 0: Kein Closure-Compiler (Standard in -O2 und darunter).

• 1: Closure-Compiler ausführen. Dies reduziert die Größe des unterstützenden JavaScript-Codes erheblich (alles außer WebAssembly oder asm.js). Beachten Sie, dass dies die Kompilierungszeit erheblich erhöht.

• 2: Führt den Closure-Compiler für *allen* ausgegebenen Code aus, sogar für die **asm.js**-Ausgabe im **asm.js**-Modus. Dies kann die Code-Größe weiter reduzieren, verhindert aber eine erhebliche Anzahl von **asm.js**-Optimierungen, daher wird es nicht empfohlen, es sei denn, Sie möchten die Code-Größe um jeden Preis reduzieren.

Hinweis

• Erwägen Sie die Verwendung von -sMODULARIZE bei der Verwendung von Closure, da es Globals auf Namen minimiert, die mit anderen im globalen Scope kollidieren könnten. MODULARIZE platziert die gesamte Ausgabe in eine Funktion (siehe src/settings.js).

• Closure minimiert standardmäßig den Namen von Module selbst! Die Verwendung von MODULARIZE löst dies ebenfalls. Eine andere Lösung besteht darin, sicherzustellen, dass eine globale Variable namens Module bereits existiert, bevor der Closure-kompilierte Code ausgeführt wird, da sie dann diese Variable wiederverwenden wird.

• Closure wird nur ausgeführt, wenn JavaScript-Optimierungen durchgeführt werden (-O2 oder höher).

--closure-args=<args>

[link] Argumente an den Closure-Compiler übergeben. Dies ist eine Alternative zu EMCC_CLOSURE_ARGS.

Zum Beispiel möchte man vielleicht eine externs-Datei übergeben, um die Minimierung von JS-Funktionen zu vermeiden, die in --pre-js- oder --post-js-Dateien definiert sind. Um Closure die Datei externs.js zu übergeben, die jene öffentlichen APIs enthält, die nicht minimiert werden sollen, würde man das Flag hinzufügen: --closure-args=--externs=pfad/zu/externs.js

--pre-js <datei>

[link] Eine Datei angeben, deren Inhalt vor dem ausgegebenen Code hinzugefügt und zusammen mit diesem optimiert wird. Beachten Sie, dass dies nicht wörtlich das Allererste in der JS-Ausgabe sein muss, z.B. wenn MODULARIZE verwendet wird (siehe src/settings.js). Wenn Sie das möchten, können Sie einfach an die Ausgabe von Emscripten anhängen; der Vorteil von --pre-js ist, dass es den Code zusammen mit dem Rest der Emscripten-Ausgabe optimiert, was eine bessere Dead-Code-Eliminierung und Minimierung ermöglicht, und es sollte nur zu diesem Zweck verwendet werden. Insbesondere sollte --pre-js-Code die Hauptausgabe von Emscripten nicht auf Weisen verändern, die den Optimierer verwirren könnten, wie z.B. die Verwendung von --pre-js + --post-js, um die gesamte Ausgabe in einen inneren Funktionsbereich zu legen (siehe MODULARIZE dafür).

–pre-js (aber nicht –post-js) ist auch nützlich, um Dinge auf dem Module-Objekt anzugeben, da es erscheint, bevor der JS Module betrachtet (zum Beispiel können Sie Module['print'] dort definieren).

--post-js <datei>

[link] Wie --pre-js, aber gibt eine Datei nach dem ausgegebenen Code aus.

--extern-pre-js <datei>

[link] Eine Datei angeben, deren Inhalt der JavaScript-Ausgabe vorangestellt wird. Diese Datei wird der endgültigen JavaScript-Ausgabe vorangestellt, nachdem alle anderen Arbeiten abgeschlossen wurden, einschließlich Optimierung, optionaler MODULARIZE-rung, Instrumentierung wie SAFE_HEAP usw. Dies ist dasselbe wie das Voranstellen dieser Datei, nachdem emcc beendet ist, und ist lediglich eine bequeme Möglichkeit dazu. (Zum Vergleich: --pre-js und --post-js optimieren den Code zusammen mit allem anderen, halten ihn im selben Gültigkeitsbereich, wenn MODULARIZE ausgeführt wird, usw.).

--extern-post-js <datei>

[link] Wie --extern-pre-js, aber am Ende angehängt.

--embed-file <datei>

[link] Eine Datei (mit Pfad) angeben, die in das generierte WebAssembly-Modul eingebettet werden soll. Der Pfad ist relativ zum aktuellen Verzeichnis zur Kompilierzeit. Wenn hier ein Verzeichnis übergeben wird, wird dessen gesamter Inhalt eingebettet.

Wenn der Befehl beispielsweise --embed-file dir/file.dat enthält, muss dir/file.dat relativ zu dem Verzeichnis existieren, in dem Sie emcc ausführen.

Hinweis

Das Einbetten von Dateien ist im Allgemeinen effizienter als das Vorladen, da es das Kopieren der Dateidaten zur Laufzeit vermeidet.

Weitere Informationen zu den Optionen --embed-file finden Sie unter Dateien packen.

--preload-file <name>

[link] Eine Datei angeben, die vor dem asynchronen Ausführen des kompilierten Codes vorgeladen werden soll. Der Pfad ist relativ zum aktuellen Verzeichnis zur Kompilierzeit. Wenn hier ein Verzeichnis übergeben wird, wird dessen gesamter Inhalt eingebettet.

Vorgeladene Dateien werden in **filename.data** gespeichert, wobei **filename.html** die Hauptdatei ist, in die Sie kompilieren. Um Ihren Code auszuführen, benötigen Sie sowohl die **.html** als auch die **.data**.

Hinweis

Diese Option ähnelt –embed-file, außer dass sie nur relevant ist, wenn HTML generiert wird (sie verwendet asynchrone binäre XHRs), oder JavaScript, das auf einer Webseite verwendet wird.

emcc führt tools/file_packager aus, um das tatsächliche Packen von eingebetteten und vorgeladenen Dateien durchzuführen. Sie können den File Packager selbst ausführen, wenn Sie möchten (siehe Packen mit dem File Packager-Tool). Sie sollten dann die Ausgabe des File Packagers in eine emcc --pre-js einfügen, damit sie vor Ihrem Hauptkompilierten Code ausgeführt wird.

Weitere Informationen zu den Optionen --preload-file finden Sie unter Dateien packen.

--exclude-file <name>

[link] Dateien und Verzeichnisse, die von –embed-file und –preload-file ausgeschlossen werden sollen. Wildcards (*) werden unterstützt.

--use-preload-plugins

[link] Weist den Dateipackager an, Preload-Plugins für die Dateien auszuführen, während sie geladen werden. Dies führt Aufgaben wie das Dekodieren von Bildern und Audio unter Verwendung der Browser-Codecs aus.

--shell-file <pfad>

[link] Der Pfadname zu einer Skelett-HTML-Datei, die bei der Generierung von HTML-Ausgaben verwendet wird. Die verwendete Shell-Datei muss dieses Token enthalten: {{{ SCRIPT }}}.

Hinweis

• Siehe src/shell.html und src/shell_minimal.html für Beispiele.

• Dieses Argument wird ignoriert, wenn ein anderes Ziel als HTML mit der Option -o angegeben wird.

--source-map-base <basis-url>

[link] Die Basis-URL für den Speicherort, an dem WebAssembly-Source-Maps veröffentlicht werden. Muss mit -gsource-map verwendet werden.

--minify 0

[wie -g1, wenn zur Kompilierzeit übergeben, sonst zur Linkzeit angewendet] Identisch mit -g1.

--js-transform <befehl>

[link] Gibt einen <befehl> an, der auf den generierten Code angewendet wird, bevor dieser optimiert wird. Dies ermöglicht es Ihnen, JavaScript zu ändern, z.B. Code hinzuzufügen oder zu entfernen, so dass diese Änderungen zusammen mit dem generierten Code optimiert werden.

<cmd> wird mit dem Dateinamen des generierten Codes als Parameter aufgerufen. Um den Code zu ändern, können Sie die Originaldaten lesen und dann daran anhängen oder sie mit den geänderten Daten überschreiben.

<cmd> wird als eine durch Leerzeichen getrennte Liste von Argumenten interpretiert, zum Beispiel führt <cmd> von **python processor.py** dazu, dass ein Python-Skript ausgeführt wird.

--bind

[link] Verknüpft mit der embind-Bibliothek. Veraltet: Verwenden Sie stattdessen -lembind.

--embind-emit-tsd <pfad>

[link] Generiert TypeScript-Definitionsdatei. Veraltet: Verwenden Sie stattdessen --emit-tsd.

--emit-tsd <pfad>

[link] Erzeugt eine TypeScript-Definitionsdatei für das Emscripten-Modul. Die Definitionsdatei enthält exportierte Wasm-Funktionen, Laufzeit-Exporte und exportierte Embind-Bindungen (falls verwendet). Um Bindungen von Embind zu generieren, wird das Programm instrumentiert und in Node ausgeführt.

--ignore-dynamic-linking

[link] Weist den Compiler an, dynamische Verknüpfung zu ignorieren (der Benutzer muss später manuell mit den Shared Libraries verknüpfen).

Normalerweise verknüpft emcc Code aus der dynamischen Bibliothek einfach, als wäre er statisch verknüpft, was fehlschlägt, wenn dieselbe dynamische Bibliothek mehr als einmal verknüpft wird. Mit dieser Option wird die dynamische Verknüpfung ignoriert, was dem Build-System ermöglicht, ohne Fehler fortzufahren.

--js-library <lib>

[link] Eine JavaScript-Bibliothek, die zusätzlich zu den Kernbibliotheken von Emscripten (src/library_*) verwendet werden soll.

-v

[allgemein] Schaltet die ausführliche Ausgabe ein.

Dies druckt die internen Unterbefehle, die von Emscripten ausgeführt werden, sowie -v an Clang.

Tipp

emcc -v ist ein nützliches Werkzeug zur Fehlerdiagnose. Es funktioniert mit oder ohne andere Argumente.

--check

[allgemein] Führt Emscriptens interne Integritätsprüfungen aus und meldet alle Probleme mit der aktuellen Konfiguration.

--cache <verzeichnis>

[allgemein] Legt das Verzeichnis fest, das als Emscripten-Cache verwendet werden soll. Der Emscripten-Cache wird verwendet, um vorgefertigte Versionen von libc, libcxx und anderen Bibliotheken zu speichern.

Wenn Sie dies in Kombination mit --clear-cache verwenden, stellen Sie sicher, dass Sie dieses Argument zuerst angeben.

Der Emscripten-Cache ist standardmäßig emscripten/cache, kann aber durch die Umgebungsvariable EM_CACHE oder die Konfigurationseinstellung CACHE überschrieben werden.

--clear-cache

[allgemein] Löscht manuell den Cache der kompilierten Emscripten-Systembibliotheken (libc++, libc++abi, libc).

Dies wird normalerweise automatisch gehandhabt, aber wenn Sie LLVM an Ort und Stelle aktualisieren (anstatt ein anderes Verzeichnis für eine neue Version zu haben), kann der Caching-Mechanismus durcheinander kommen. Das Löschen des Caches kann seltsame Probleme im Zusammenhang mit Cache-Inkompatibilitäten beheben, wie z.B. das Scheitern von *Clang* beim Verknüpfen mit Bibliotheksdateien. Dies löscht auch andere zwischengespeicherte Daten. Nach dem Löschen des Caches wird dieser Prozess beendet.

Standardmäßig werden dabei auch alle heruntergeladenen Ports gelöscht, da das Ports-Verzeichnis normalerweise im Cache-Verzeichnis liegt.

--use-port=<port>

[kompilieren+linken] Verwendet den angegebenen Port. Wenn Sie mehr als einen Port verwenden müssen, können Sie diese Option mehrmals verwenden (z.B.: --use-port=sdl2 --use-port=bzip2). Ein Port kann Optionen haben, die durch : getrennt sind (z.B.: --use-port=sdl2_image:formats=png,jpg). Um einen externen Port zu verwenden, geben Sie den Pfad zum Port direkt an (z.B.: --use-port=/pfad/zu/mein_port.py). Um weitere Informationen über einen Port zu erhalten, verwenden Sie die Option help (z.B.: --use-port=sdl2_image:help). Um die Liste der verfügbaren Ports zu erhalten, verwenden Sie --show-ports.

--clear-ports

[allgemein] Löscht manuell die lokalen Kopien der Ports aus den Emscripten Ports Repos (sdl2, etc.). Dies löscht auch den Cache, um ihre Builds zu entfernen.

Sie sollten dies nur tun müssen, wenn ein Problem auftritt und Sie möchten, dass alle von Ihnen verwendeten Ports von Grund auf neu heruntergeladen und gebaut werden. Nach Abschluss dieses Vorgangs wird der Prozess beendet.

--show-ports

[allgemein] Zeigt die Liste der verfügbaren Projekte in den Emscripten Ports Repos an. Nach Abschluss dieses Vorgangs wird der Prozess beendet.

-Wwarn-absolute-paths

[kompilieren+linken] Aktiviert Warnungen bezüglich der Verwendung von absoluten Pfaden in den Befehlszeilenanweisungen -I und -L. Dies wird verwendet, um vor der unbeabsichtigten Verwendung von absoluten Pfaden zu warnen, was manchmal gefährlich ist, wenn auf nicht-portable lokale System-Header verwiesen wird.

--proxy-to-worker

[link] Führt den Hauptanwendungscode in einem Worker aus, indem Ereignisse an ihn und Ausgaben von ihm weitergeleitet werden. Wenn HTML ausgegeben wird, wird eine **.html**-Datei und eine separate **.js**-Datei mit dem JavaScript, das in einem Worker ausgeführt werden soll, ausgegeben. Wenn JavaScript ausgegeben wird, enthält der Zieldateiname den Teil, der im Hauptthread ausgeführt werden soll, während eine zweite **.js**-Datei mit dem Suffix „.worker.js“ den Worker-Teil enthält.

--emrun

[link] Ermöglicht, dass die generierte Ausgabe das Befehlszeilentool emrun berücksichtigt. Dies ermöglicht die Erfassung von stdout, stderr und exit(returncode) beim Ausführen der generierten Anwendung über emrun. (Dies aktiviert EXIT_RUNTIME=1, was ein normales Beenden der Laufzeit mit der Übergabe eines Rückgabecodes ermöglicht.)

--cpuprofiler

[link] Bettet einen einfachen CPU-Profiler in die generierte Seite ein. Verwenden Sie dies, um eine oberflächliche interaktive Performance-Profilierung durchzuführen.

--memoryprofiler

[link] Bettet einen Speicherallokations-Tracker in die generierte Seite ein. Verwenden Sie dies, um die Anwendungsauslastung des Emscripten HEAP zu profilieren.

--threadprofiler

[link] Bettet einen Thread-Aktivitäts-Profiler auf der generierten Seite ein. Verwenden Sie dies, um die Anwendungsauslastung von pthreads bei der Erstellung von Multithread-Builds (-pthread) zu profilieren.

--em-config <pfad>

[allgemein] Gibt den Speicherort der Konfigurationsdatei **.emscripten** an. Wenn nicht angegeben, sucht Emscripten zuerst im Emscripten-Verzeichnis selbst und dann im Home-Verzeichnis des Benutzers (~/.emscripten) nach .emscripten. Dies kann über die Umgebungsvariable EM_CONFIG überschrieben werden.

--valid-abspath <pfad>

[kompilieren+linken] Beachten Sie einen zulässigen absoluten Pfad, vor dem wir nicht warnen sollten (absolute Include-Pfade werden normalerweise beanstandet, da sie sich auf lokale System-Header usw. beziehen können, die wir beim Cross-Kompilieren vermeiden müssen).

-o <ziel>

[link] Beim Verknüpfen einer ausführbaren Datei definiert die Dateinamenerweiterung target den zu generierenden Ausgabetyp

• <name> **.js** : JavaScript (+ separate **<name>.wasm**-Datei, wenn WebAssembly ausgegeben wird). (Standard)

• <name> **.mjs** : ES6 JavaScript-Modul (+ separate **<name>.wasm**-Datei, wenn WebAssembly ausgegeben wird).

• <name> **.html** : HTML + separate JavaScript-Datei (**<name>.js**; + separate **<name>.wasm**-Datei, wenn WebAssembly ausgegeben wird).

• <name> **.wasm** : WebAssembly ohne JavaScript-Support-Code („standalone Wasm“; dies aktiviert STANDALONE_WASM).

Diese Regeln gelten nur beim Linken. Beim Kompilieren zu Objektcode (siehe -c unten) ist der Name der Ausgabedatei irrelevant.

-c

[kompilieren] Weist emcc an, eine Objektdatei auszugeben, die dann mit anderen Objektdateien verknüpft werden kann, um eine ausführbare Datei zu erstellen.

--output_eol windows|linux

[link] Gibt das Zeilenende an, das für die ausgegebenen Textdateien generiert werden soll. Wenn „--output_eol windows“ übergeben wird, haben die endgültigen Ausgabedateien Windows rn-Zeilenenden. Mit „--output_eol linux“ werden die endgültig generierten Dateien mit Unix n-Zeilenenden geschrieben.

--cflags

[andere] Gibt die Flags aus, die emcc an clang übergeben würde, um Quellcode in Objektform zu kompilieren. Sie können dies verwenden, um clang selbst aufzurufen und dann emcc für diese Ausgaben nur für die finale Verknüpfung + Konvertierung nach JS auszuführen.

Umgebungsvariablen

emcc wird von mehreren Umgebungsvariablen beeinflusst, wie unten aufgeführt

• EMMAKEN_JUST_CONFIGURE [andere]

• EMCC_AUTODEBUG [kompilieren+linken]

• EMCC_CFLAGS [kompilieren+linken]

• EMCC_CORES [allgemein]

• EMCC_DEBUG [allgemein]

• EMCC_DEBUG_SAVE [allgemein]

• EMCC_FORCE_STDLIBS [link]

• EMCC_ONLY_FORCED_STDLIBS [link]

• EMCC_LOCAL_PORTS [kompilieren+linken]

• EMCC_STDERR_FILE [allgemein]

• EMCC_CLOSURE_ARGS [link] Argumente, die an den Closure Compiler übergeben werden sollen

• EMCC_STRICT [allgemein]

• EMCC_SKIP_SANITY_CHECK [allgemein]

• EM_IGNORE_SANITY [allgemein]

• EM_CONFIG [allgemein]

• EM_LLVM_ROOT [kompilieren+linken]

• _EMCC_CCACHE [allgemein] Interne Einstellung, die von emsdk auf 1 gesetzt wird, wenn es mit dem ccache-Compiler-Frontend integriert wird

Suchen Sie nach 'os.environ' in emcc.py, um zu sehen, wie diese verwendet werden. Am interessantesten ist möglicherweise EMCC_DEBUG, das den Compiler dazu zwingt, seine Build- und temporären Dateien in ein temporäres Verzeichnis zu kippen, wo sie überprüft werden können.