Emscriptenコンパイラ設定¶

以下は、コマンドラインで -s を介して emscripten に渡すことができる設定の完全なリストです。例：-sASSERTIONS または -sASSERTIONS=0。詳細については、emcc ドキュメントを参照してください。

特に明記しない限り、これらの設定はリンク時にのみ適用され、コンパイル中は効果がありません。

ASSERTIONS¶

ランタイムアサーションを追加するかどうか。これは、JSとシステムライブラリのビルド方法の両方に影響します。ASSERTIONS == 2 は、非常に遅くなる可能性がある、より多くのランタイムチェックを提供します。たとえば、内部の dlmalloc アサーションが含まれます。

デフォルト値：1

STACK_OVERFLOW_CHECK¶

生成されたコードにどの種類のスタック破壊チェックを生成するかを選択します。ASSERTIONS=1 でビルドすると、STACK_OVERFLOW_CHECK のデフォルトは 1 になります。ASSERTIONS=1 が -O0 でのデフォルトであり、-O0 自体がデフォルトの最適化レベルであるため、これは、他の設定がない場合、この設定も事実上 1 にデフォルト設定されることを意味します。

0: スタックオーバーフローはチェックされません。
1：スタックの先頭にセキュリティクッキーを追加し、各ティックの終了時と終了時にチェックします（実質的にパフォーマンスオーバーヘッドはゼロ）。
2：上記と同じですが、すべてのスタックポインタ割り当てにチェックを追加する binaryen パスも実行します。パフォーマンスコストはわずかです。

デフォルト値：0

CHECK_NULL_WRITES¶

STACK_OVERFLOW_CHECK が有効になっている場合、アドレスゼロへの書き込みもチェックします。これは、NULL ポインタの使用を検出するのに役立ちます。（たとえば、アドレスゼロからの読み取りで常にゼロを返すようにしたい場合は）この追加チェックをスキップする場合は、ここで無効にすることができます。この設定は、STACK_OVERFLOW_CHECK が無効になっている場合は効果がありません。

デフォルト値：true

VERBOSE¶

1に設定すると、コンパイル中により詳細な出力が生成されます。[全般]

デフォルト値：false

INVOKE_RUN¶

main() 関数を実行するかどうか。生成されたコードを独自に埋め込み、適切なタイミングで自分で main() を呼び出す場合は無効にします（これは、Module.callMain() を使用して、コマンドライン引数のオプションパラメータを使用して実行できます）。

デフォルト値：true

EXIT_RUNTIME¶

0 の場合、main() が完了してもランタイムは終了しません（たとえば、ブラウザのメインイベントループから後でコードを実行できます）。atexit() も実行されず、stdio ストリームのフラッシュなど、ランタイムシャットダウンのコードを含めることを回避できます。atexit() または stdio ストリームを終了時にフラッシュする場合は、これを 1 に設定します。この設定は、STANDALONE_WASM モードで自動的に制御されます。

コマンド（main 関数を持つ）の場合、これは常に 1 です。
リアクタ（main 関数がない）の場合、これは常に 0 です。

デフォルト値：false

STACK_SIZE¶

合計スタックサイズ。スタックを拡大する方法はないため、この値はプログラムの要件に対して十分に大きくなければなりません。アサーションが有効になっている場合、これを超えないことをアサートします。それ以外の場合は、何も警告なく失敗します。

デフォルト値：64*1024

MALLOC¶

使用する malloc()/free()（次の中から）：

dlmalloc - 強力な汎用 malloc

emmalloc - emscripten 用に設計されたシンプルでコンパクトな malloc

emmalloc-debug - emmalloc を使用し、追加のアサーションチェックを追加します

emmalloc-memvalidate - アサーション + ヒープ整合性チェックを使用して emmalloc を使用します。

emmalloc-verbose - アサーション + 詳細ログを使用して emmalloc を使用します。

emmalloc-memvalidate-verbose - アサーション + ヒープ整合性チェック + 詳細ログを使用して emmalloc を使用します。

mimalloc - 強力なマルチスレッドアロケータ。これは、malloc() の競合がある大規模なアプリケーションで推奨されますが、より大きく、より多くのメモリを使用します。

none - malloc() の実装は提供されていませんが、malloc() と free() を自分で実装する必要があります。

dlmalloc は、分割メモリやその他の特別なモードで必要であり、これらのケースでは自動的に使用されます。一般に、これらの特別なモードのいずれも必要ない場合、および非常に多くの小さなオブジェクトを割り当てない場合は、emmalloc の方が小さいため使用する必要があります。それ以外の場合、多くの小さなオブジェクトを割り当てる場合は、通常、dlmalloc を使用する価値があります。dlmalloc は、emmalloc が実行しない（内部データ構造内のメタデータの破損に気づくなど）追加のセキュリティチェックが必要な場合にも適しています。

デフォルト値：「dlmalloc」

ABORTING_MALLOC¶

1 の場合、malloc が失敗すると abort() します。これは非標準の動作ですが、Web では、最初にすべて割り当てる必要がある固定量のメモリがあるため、理にかなっています。(a) malloc の失敗は他のプラットフォームよりもはるかに多く、(b) 人々は初期割り当て（INITIAL_MEMORY）がどのくらいの大きさでなければならないかを知る方法が必要です。これを 0 に設定すると、失敗したときに NULL (0) を返すという標準の malloc 動作が得られます。

ALLOW_MEMORY_GROWTH を設定すると、標準システムのように、成長を試みて失敗時に malloc から 0 を返すという動作がデフォルトになるため、これはオフになります。ただし、このフラグを設定して上書きすることもできます。これは、ほとんど下位互換性のある変更です。以前は、成長がオンの場合、このオプションは無視されていました。現在の動作は、成長によりデフォルトでオフになるため、フラグを指定しなかったユーザーの場合は何も変わりません。ただし、指定した場合、以前は効果がなかったものが、今回は効果があります。そうしたくない場合は、リンク時に渡さないようにするだけです。

この設定は、C++ の operator new の動作には影響しないことに注意してください。例外が無効になっている場合、この関数は常に割り当ての失敗時にアボートします。失敗時に new が 0 を返すようにする場合は、std::nothrow とともに使用します。

デフォルト値：true

INITIAL_HEAP¶

プログラムで使用可能な初期ヒープメモリ量。これは、sbrk、malloc、および new を介した動的割り当てに使用できるメモリ領域です。

INITIAL_MEMORY とは異なり、この設定により、プログラムのメモリの静的領域と動的領域を個別に拡張できます。ほとんどの場合、INITIAL_MEMORY ではなく、この設定を使用することをお勧めします。ただし、この設定は、インポートされたメモリでは機能しません（たとえば、動的リンクが使用されている場合）。

デフォルト値：16777216

INITIAL_MEMORY¶

使用する初期メモリ量。これより多くのメモリを使用すると、ヒープが拡張されます。これにより、型付き配列を使用する場合はコストがかかる可能性があります。その場合、古いヒープを新しいヒープにコピーする必要があるからです。ALLOW_MEMORY_GROWTH が設定されている場合、この初期メモリ量は後で増やすことができます。設定されていない場合は、これが最終的な合計メモリ量になります。

デフォルトでは、この値は、INITIAL_HEAP、STACK_SIZE、および入力モジュールの静的データのサイズに基づいて計算されます。

（このオプションは、以前は TOTAL_MEMORY と呼ばれていました。）

デフォルト値：-1

MAXIMUM_MEMORY¶

wasm モジュール内の最大メモリサイズ（バイト単位）を設定します。これは、ALLOW_MEMORY_GROWTH が設定されている場合にのみ関連します。成長がない場合、INITIAL_MEMORY のサイズが最終的なメモリサイズになるからです。

ここでデフォルト値は 2GB であり、これは、デフォルトでメモリの拡張を有効にした場合、最大 2GB まで拡張できますが、それ以上は拡張できないことを意味します。2GB はいくつかの理由から自然な制限です。

最大ヒープサイズが 2GB を超える場合、ポインタは JavaScript で符号なしである必要があり、コードサイズが増加します。2GB を超えるヒープを明示的に選択しない限り、メモリ拡張ビルドを大きくしたくありません。

歴史的に、VM は 2GB+ を超えるメモリをサポートしておらず、最近（2020 年 3 月）になってサポートが表示され始めました。サポートが限られているため、すべての VM で動作しない可能性のあるビルドを取得するのではなく、2GB+ を超えるヒープを明示的に選択する方が安全です。

2GB を超えるメモリを使用するには、これを 4GB のような大きな値に設定します。

（このオプションは、以前は WASM_MEM_MAX および BINARYEN_MEM_MAX と呼ばれていました。）

デフォルト値：2147483648

ALLOW_MEMORY_GROWTH¶

falseの場合、(INITIAL_MEMORY)よりも多くのメモリを割り当てようとするとエラーで中断します。trueの場合、メモリ配列をランタイム時にシームレスかつ動的に拡張します。Chromeでのメモリ拡張のパフォーマンスについては、https://code.google.com/p/v8/issues/detail?id=3907を参照してください。メモリの拡張は、一度作成するとサイズ変更できないため、JSの型付き配列ビューを置き換えることを意味します。（wasmではメモリを拡張できますが、JS用の新しいビューを作成する必要があります。）このオプションを有効にすると、ABORTING_MALLOCが無効になります。言い換えれば、ALLOW_MEMORY_GROWTHは、mallocが失敗時に0を返すという標準的な動作と、必要に応じてシステムからより多くのメモリを割り当てることができる動作の両方を完全に有効にします。

デフォルト値：false

MEMORY_GROWTH_GEOMETRIC_STEP¶

ALLOW_MEMORY_GROWTHがtrueの場合、この変数は、リサイズ時のヒープの幾何学的過剰成長率を指定します。ヒープの過剰成長を完全に無効にするにはMEMORY_GROWTH_GEOMETRIC_STEP=0を指定し、例えば、MEMORY_GROWTH_GEOMETRIC_STEP=1.0を指定すると、各拡張ステップでヒープが2倍（+100％）になります。この値が大きいほど、WebAssemblyヒープはメモリリサイズによるパフォーマンスの低下を軽減するために多くのメモリを過剰に予約します。この値が小さいほど、ヒープが拡張するときにパフォーマンスが低下してより多くのメモリが節約されます（プロファイルによると約20ミリ秒のオーダーです）。

デフォルト値：0.20

MEMORY_GROWTH_GEOMETRIC_CAP¶

最大幾何学的過剰成長サイズ（バイト単位）の上限を指定します。この値を使用して、幾何学的拡張が特定のレートを超えないように制限します。上限を無効にして無制限のサイズ増加を許可するには、MEMORY_GROWTH_GEOMETRIC_CAP=0を渡します。

デフォルト値：96*1024*1024

MEMORY_GROWTH_LINEAR_STEP¶

ALLOW_MEMORY_GROWTHがtrueで、MEMORY_GROWTH_LINEAR_STEP == -1の場合、幾何学的メモリ過剰成長が利用されます（上記の変数）。幾何学的過剰成長率を一定の拡張ステップサイズに置き換えるには、MEMORY_GROWTH_LINEAR_STEPをWASMページサイズ（64KB）の倍数（例：16MB）に設定します。MEMORY_GROWTH_LINEAR_STEPが使用されている場合、変数MEMORY_GROWTH_GEOMETRIC_STEPおよびMEMORY_GROWTH_GEOMETRIC_CAPは無視されます。

デフォルト値：-1

MEMORY64¶

コンパイル対象の「アーキテクチャ」。0はデフォルトのwasm32、1は完全なエンドツーエンドのwasm64モード、2はclang/lld用のwasm64ですが、Binaryenでwasm32に下げられます（内部でi64ポインターを使用しながら、wasm32エンジンで実行できるようにするため）。WASM_BIGINTを想定しています。

注記

リンクとコンパイルの両方で適用可能

注記

これは実験的な設定です

デフォルト値：0

INITIAL_TABLE¶

MAIN_MODULEまたはSIDE_MODULEが使用されている場合（それ以外の場合ではない）、テーブルの初期サイズを設定します。通常、Emscriptenはリンク時にテーブルのサイズを決定できますが、SPLIT_MODULEモードでは、wasm-splitがテーブルを拡張する必要があることが多いため、計装されたビルド用のJSに組み込まれたテーブルサイズは、モジュール分割後には小さすぎます。これは、ユーザーが両方のビルドで一貫性のある十分に大きなテーブルサイズを指定できるようにするためのハックです。この設定はいつでも削除される可能性があり、SPLIT_MODULEおよび動的リンクと組み合わせて使用する場合を除き、使用しないでください。

デフォルト値：-1

ALLOW_TABLE_GROWTH¶

trueの場合、ランタイム時にテーブルにさらに関数を追加できます。これは動的リンクに必要であり、そのモードでは自動的に設定されます。

1の場合、demangleおよびstackTraceJSライブラリ関数をエクスポートします。

注記

この設定は非推奨です

デフォルト値：false

LIBRARY_DEBUG¶

ライブラリ呼び出し（library * .js）に入るときに出力します。また、ログを停止するためにランタイムでruntimeDebugをオフにすることができ、必要に応じてオンに戻すことができます。C++で設定する簡単な方法は次のとおりです。

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

デフォルト値：false

POLYFILL_OLD_MATH_FUNCTIONS¶

設定されている場合、Math.clz32、Math.trunc、Math.imul、Math.froundのポリフィルを有効にします。

デフォルト値：false

LEGACY_VM_SUPPORT¶

古い JavaScript エンジンとの互換性のためのエミュレーションを有効にするには、これを設定します。これにより、まれな古いブラウザやシェル環境を含め、あらゆる場所でコードが動作する可能性が最大限に高まります。具体的には、

Math.clz32、Math.trunc、Math.imul、Math.fround のポリフィルを追加します。(-sPOLYFILL_OLD_MATH_FUNCTIONS)
WebAssembly を無効にします。（-sWASM=0 と組み合わせる必要があります）
すべてのブラウザバージョンをサポートするために、MIN_X_VERSION 設定を 0 に調整します。
必要に応じて、zeroMemory ユーティリティ関数で TypedArray.fill を回避します。

上記オプションは個別に設定することもできます。

デフォルト値：false

ENVIRONMENT¶

JS 出力が実行可能なランタイム環境を指定します。最大の移植性のために、これはすべての環境をサポートするように構成することも、全体的なコードサイズを削減するために制限することもできます。サポートされている環境は次のとおりです。

‘web’ - 通常の Web 環境。
‘webview’ - web と同様ですが、Cordova のような webview 内です。ほとんどの場合 “web” と同じとみなされます
‘worker’ - Web Worker 環境。
‘node’ - Node.js。
‘shell’ - d8、js、jsc などの JS シェル。

この設定は、"web,worker" のように、これらの環境のコンマ区切りリストにすることができます。これが空文字列の場合、すべての環境がサポートされます。

ここで認識される環境のセットは、ENVIRONMENT_IS_* を使用してランタイム時に識別するセットと同一ではないことに注意してください。具体的には

ランタイム時に pthread であるかどうかを検出しますが、それはワーカーに対して設定されており、メインファイルに対しては設定されないため、ここで指定することは意味がありません。
webview ターゲットは基本的に web のサブセットです。web とともに (例: "web,webview") 指定する必要があり、コンパイル時のコード生成でのみ使用され、ランタイムの動作変更はありません。

デフォルトでは、d8、js、jsc の直接使用は非常にまれであるため、'shell' 環境は含めないことに注意してください。

デフォルト値: ‘web,webview,worker,node’

LZ4¶

lz4 圧縮ファイルパッケージをサポートするには、これを有効にします。これらはメモリに圧縮された状態で格納され、オンザフライで解凍されるため、解凍されたデータ全体を一度にメモリに格納することを回避できます。ファイルパッカーを個別に実行する場合でも、このフラグを指定してメインプログラムをビルドし、ファイルパッカーに –lz4 を渡す必要があります。（クライアントで LZ4.loadPackage() を使用して手動で圧縮することもできますが、あまり推奨されません。）制限事項

LZ4 圧縮ファイルは必要なときにのみ解凍されるため、ブラウザコーデックを使用した画像の事前デコードや preloadPlugin のような特別なプリロード操作には使用できません。
LZ4 ファイルは読み取り専用です。

デフォルト値：false

DISABLE_EXCEPTION_CATCHING¶

例外を実際にキャッチするコードの生成を無効にします。例外のオーバーヘッドは現在サイズと速度の点で非常に高いため（将来的には wasm で改善されるはずです）、この無効化はデフォルトで有効になっています。例外が無効になっている場合、実際に例外が発生してもキャッチされず、プログラムは停止します（したがって、これによりサイレントエラーが発生することはありません）。

注記

これにより、速度の主な問題である例外のキャッチが削除されますが、決してキャッチされないスローされた例外が含まれている可能性があるため（たとえば、std::vector を使用するだけでもそれが発生する可能性があります）、-fno-exceptions でソースファイルをビルドして、すべての例外コードのオーバーヘッドを実際に取り除く必要があります。-fno-rtti も役立つ場合があります。

このオプションは、EXCEPTION_CATCHING_ALLOWED と相互に排他的です。

このオプションは、Emscripten (JavaScript ベース) の例外処理にのみ適用され、ネイティブの Wasm 例外処理は制御しません。

[コンパイル + リンク] - コンパイル時のユーザーコードとリンク時のシステムライブラリに影響します

デフォルト値：1

EXCEPTION_CATCHING_ALLOWED¶

リストされた関数でのみ例外をキャッチすることを有効にします。このオプションは、DISABLE_EXCEPTION_CATCHING=0 のより正確なバージョンとして機能します。

このオプションは、DISABLE_EXCEPTION_CATCHING と相互に排他的です。

このオプションは、Emscripten (JavaScript ベース) の例外処理にのみ適用され、ネイティブの Wasm 例外処理は制御しません。

[コンパイル + リンク] - コンパイル時のユーザーコードとリンク時のシステムライブラリに影響します

デフォルト値: []

DISABLE_EXCEPTION_THROWING¶

内部: Emscripten が例外スロー (C++ 'throw') サポートライブラリにリンクするかどうかを追跡します。これは直接設定する必要はありませんが、ビルドに -fno-exceptions を渡して例外サポートを無効にします。（これは基本的には -fno-exceptions ですが、個々の .cpp ファイルのコンパイル時ではなく、最終リンク時にチェックされます）プログラムにスローコード (一部のソースファイルが -fno-exceptions でコンパイルされていない) が含まれており、このフラグがリンク時に設定されている場合、例外スローコードがリンクされていないため、未定義のシンボルでエラーが発生します。その場合は、オプションの設定を解除するか（例外が必要な場合）、ソースファイルのコンパイルを修正して、実際に例外が使用されていないようにする必要があります。TODO(sbc): (テストコードでの使用のため現在ブロックされている) settings_internal に移動します。

このオプションは、Emscripten (JavaScript ベース) の例外処理にのみ適用され、ネイティブの Wasm 例外処理は制御しません。

デフォルト値：false

EXPORT_EXCEPTION_HANDLING_HELPERS¶

例外メッセージの印刷関数である 'getExceptionMessage' を、EXPORTED_FUNCTIONS に必要なシンボルを追加することにより、JS ライブラリで使用できるようにします。

これは、Emscripten EH と Wasm EH の両方で機能します。JS から例外をキャッチすると、Emscripten EH の場合はユーザーがスローした値が、Wasm EH の場合は WebAssembly.Exception オブジェクトが与えられます。'getExceptionMessage' は、Emscripten EH の場合はユーザーがスローした値を、Wasm EH の場合は WebAssembly.Exception オブジェクトを受け取ります。つまり、どちらの場合も、キャッチされた例外を関数に直接渡すことができます。

Wasm EH と共に使用する場合、このオプションは JS ライブラリでこれらの関数を追加で提供します

getCppExceptionTag: C++ タグを返します
getCppExceptionThrownObjectFromWebAssemblyException: WebAssembly.Exception オブジェクトを指定すると、Wasm メモリ内の実際のユーザーがスローした C++ オブジェクトのアドレスを返します。

このオプションを設定すると、JS ライブラリに参照カウントを増減する関数 ('incrementExceptionRefcount' と 'decrementExceptionRefcount') も追加されます。これは、JS から例外をキャッチした場合、メモリリークを防ぐために手動で参照カウントを操作する必要があるためです。実行する必要があることは、使用する EH の種類によって異なります (https://github.com/emscripten-core/emscripten/issues/17115)。

使用例については、test/test_core.py の test_EXPORT_EXCEPTION_HANDLING_HELPERS を参照してください。

デフォルト値：false

EXCEPTION_STACK_TRACES¶

デフォルト値：false

ASYNCIFY_STACK_SIZE¶

asyncify スタックのサイズ - アンワインド/リワインド情報を格納するために使用される領域。これは、コールスタックとローカルを格納するのに十分な大きさである必要があります。小さすぎると、「到達不能」命令の実行により wasm トラップが発生します。その場合は、このサイズを大きくする必要があります。

デフォルト値: 4096

ASYNCIFY_REMOVE¶

Asyncifyの削除リストが提供された場合、そのリストにある関数は、必要と思われる場合でもインストルメントされません。これは、全プログラム解析ではわからないことを知っている場合に便利です。例えば、特定の非間接呼び出しが安全でアンワインドしないことを知っている場合などです。しかし、リストを間違えると、動作が壊れてしまいます（そして、本番ビルドでは、テスト中に見逃したコードパスにユーザー入力が到達する可能性があるため、正しくリストを作成できたかを知ることは困難です）。したがって、本当に何をすべきかを知っていて、スピードとサイズを最大限に最適化する必要がある場合以外は、推奨されません。

このリストの名前は、WebAssemblyの名前セクションの名前です。wasmバックエンドは、通常のC++のマングリングではなく、人間が読める形式でこれらの名前を出力します。たとえば、_ZN6Struct4FuncEvではなく、Struct::func()と記述する必要があります。CもC++とは異なり、Cの名前はパラメータで終わりません。結果として、C++のfoo(int)はCでは単にfooとして表示されます（C++には、オーバーロードされた関数を区別する必要があるため、パラメータがあります）。リストにない名前がある場合は、コンソールに警告が表示されます（インライン化などにより、-O0ビルドと-O1ビルドの両方で単一のリストが機能しない可能性があるため、これはエラーではありません）。wasmバイナリを直接検査するか、wasm-objdumpやwasm-disなどを使用して、実際の名を探すことができます。

単純な*ワイルドカードマッチングがサポートされています。

オペレーティングシステムのシェルまたはビルドシステムのエスケープの制限に対処するために、次の置換を行うことができます。

‘ ‘ -> .,
& -> #,
, -> ?.

つまり、関数“foo(char const*, int&)”は、コマンドラインで“foo(char.const*?.int#)”として入力できます。

注意: 空白は関数シグネチャの一部です！つまり、“foo(char const , int &)”は“foo(char const, int&)”と一致せず、“foo(const char*, int &)”とも一致しません。

デフォルト値: []

ASYNCIFY_ADD¶

Asyncifyの追加リストにある関数は、インストルメントされる関数のリストに追加されます。つまり、Asyncifyがインストルメントする必要がないと考える場合でも、インストルメントされます。デフォルトでは、すべてが可能な限り安全な方法でインストルメントされるため、これは、IGNORE_INDIRECTを使用し、このリストを使用して、インストルメントする必要がある一部の非間接呼び出しを修正する場合にのみ役立ちます。

ワイルドカードマッチングと文字置換を含む、名前に関するASYNCIFY_REMOVEの注意を参照してください。

デフォルト値: []

ASYNCIFY_PROPAGATE_ADD¶

有効にすると、インストルメントの状態は追加リストから伝播されます。つまり、その呼び出し元、およびその呼び出し元の呼び出し元などが伝播されます。無効にすると、すべての呼び出し元を（only-listのように）手動で追加リストに追加する必要があります。

デフォルト値：true

ASYNCIFY_ONLY¶

Asyncifyのonly-listが提供された場合、リストにある関数のみがインストルメントされます。remove-listと同様に、これを間違えるとアプリケーションが壊れます。

ワイルドカードマッチングと文字置換を含む、名前に関するASYNCIFY_REMOVEの注意を参照してください。

デフォルト値: []

ASYNCIFY_ADVISE¶

有効にすると、どの関数がインストルメントされたか、またその理由が出力されます。

デフォルト値：false

ASYNCIFY_LAZY_LOAD_CODE¶

遅延コード読み込みを許可します。emscripten_lazy_load_code()が記述されている場所で、実行を一時停止し、残りのコードを読み込んでから、再開します。

デフォルト値：false

ASYNCIFY_DEBUG¶

asyncify内部からのランタイムデバッグロギング。

1：最小限のロギング。
2：詳細なロギング。

デフォルト値：0

ASYNCIFY_EXPORTS¶

非推奨。代わりにJSPI_EXPORTSを使用してください。

注記

この設定は非推奨です

デフォルト値: []

JSPI¶

JavaScript Promise IntegrationプロポーザルのVMサポートを使用します。これにより、wasmを変更するオーバーヘッドなしに非同期操作を実行できます。これは仕様の議論が進行中であるため、現在実験的です。 https://github.com/WebAssembly/js-promise-integration/を参照してください。TODO: このモードで以下のどのフラグがまだ関連しているかを文書化してください（たとえば、IGNORE_INDIRECTなどは不要です）。

デフォルト値：0

JSPI_EXPORTS¶

非同期になるエクスポートされたモジュール関数のリスト。各エクスポートは、結果で解決されるPromiseを返します。非同期インポート（JSPI_IMPORTSにリストされている）を呼び出すエクスポートはすべて、ここに含める必要があります。

デフォルトでは、mainが含まれています。

デフォルト値: []

JSPI_IMPORTS¶

非同期処理を行う可能性のあるインポートされたモジュール関数のリスト。インポートされた関数は、非同期処理を行うときにPromiseを返す必要があります。

--js-libraryを使用する場合は、この設定の代わりに、ライブラリ内で<function_name>_async:: trueで関数をマークできます。

デフォルト値: []

EXPORTED_RUNTIME_METHODS¶

デフォルトでModuleにエクスポートされるランタイム要素。以前はここでかなり多くエクスポートしていましたが、すべて削除しました。ランタイムからエクスポートしたいものには、EXPORTED_RUNTIME_METHODSを使用する必要があります。これはメソッドだけでなく、あらゆるJSライブラリ要素を対象としているため、名前が少し誤解を招く可能性があることに注意してください。たとえば、このリストに「FS」を含めることで、FSオブジェクトをエクスポートできます。

デフォルト値: []

EXTRA_EXPORTED_RUNTIME_METHODS¶

非推奨。代わりにEXPORTED_RUNTIME_METHODSを使用してください。

注記

この設定は非推奨です

デフォルト値: []

INCOMING_MODULE_JS_API¶

Moduleオブジェクト上のJSの受信値のうち、関心のあるもののリスト。値がこのリストにない場合、Moduleオブジェクトで提供するかどうかを確認するコードは出力しません。たとえば、次のものがある場合

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

次に、MODULE_JS_APIには「print」と「preRun」が含まれている必要があります。含まれていない場合、その値を読み取って使用するコードは出力されない可能性があります。言い換えれば、このオプションを使用すると、コンパイル時に静的に、実行時に提供するModule JS値のリストを設定できるため、コンパイラは最適化を改善できます。

このリストを[]に設定するか、少なくとも実際に使用する短い簡潔な名前のセットに設定すると、コードサイズを削減するのに非常に役立ちます。デフォルトでは、リストには一般的に使用される記号のセットが含まれています。

FIXME: すべてが必要な場合、これは単に0にする必要がありますか？

デフォルト値：（複数行の値、settings.jsを参照）

CASE_INSENSITIVE_FS¶

ゼロ以外の値に設定すると、提供された仮想ファイルシステムは、WindowsやmacOSのように大文字と小文字を区別せずに扱われます。0に設定すると、VFSはLinuxのように大文字と小文字を区別します。

デフォルト値：false

FILESYSTEM¶

0に設定すると、ファイルシステムのサポートは組み込まれません。純粋な計算だけを実行する場合、ファイルを読み込んだり、ストリーム（fprintfやその他のstdio.hのものなど）を使用したり、関連するものを使用したりしない場合に役立ちます。1つの例外は、printfとputsに対する部分的なハック的なサポートがあることです。コンパイラは、システムコールの使用法（これは静的です）に完全なファイルシステムが必要ないことを検出した場合、これを自動的に設定します。ファイルシステムのサポートが必要な場合は、FORCE_FILESYSTEMを使用してください。

デフォルト値：true

FORCE_FILESYSTEM¶

静的に使用されていないように見える場合でも、完全なファイルシステムのサポートを含めるようにします。たとえば、Cコードでファイルを使用していなくても、ファイルを使用するJSを含めている場合は、これが必要になる場合があります。

デフォルト値：false

NODERAWFS¶

NODERAWFSファイルシステムバックエンドのサポートを有効にします。これは、FS.mount()を実行する必要なしに、通常のファイルシステムアクセスをすべて直接Node.js操作に置き換えるため、特別なバックエンドです。このバックエンドはNode.jsでのみ機能します。初期作業ディレクトリは、VFSルートディレクトリではなく、process.cwd()と同じになります。このモードでは、Node.jsを使用してOS上の実際のローカルファイルシステムに直接アクセスするため、コードは必ずしもOS間で移植可能であるとは限りません。Node.jsプログラムが移植可能な範囲で移植可能になります。つまり、基盤となるOSがアクセス許可やエラーなどを処理する方法の違いが顕著になる可能性があります。

デフォルト値：false

NODE_CODE_CACHING¶

これにより、コンパイルされたwasmモジュールが$WASM_BINARY_NAME.$V8_VERSION.cachedという名前のファイルに保存され、後続の実行時にロードされます。これにより、nodeのv8からコンパイルされたwasmコードがキャッシュされ、後続の実行時のコンパイルが不要になり、起動が大幅に速くなります。nodeで使用されるV8のバージョンはキャッシュ名に含まれているため、別のバージョンからキャッシュされたコードをロードしようとすることはありません。これは静かに失敗します（正常にロードされているように見えますが、実際には再コンパイルされます）。

確実に機能することがわかっているバージョンはnode 12.9.1のみです。これは回帰しているため、https://github.com/nodejs/node/issues/18265#issuecomment-622971547を参照してください。
前述したように、.cachedファイルのデフォルトの場所は、wasmバイナリと同じ場所です。それが読み取り専用ディレクトリにある場合は、別の場所に配置する必要がある場合があります。そのためにlocateFile()フックを使用できます。

デフォルト値：false

EXPORTED_FUNCTIONS¶

明示的にエクスポートされるシンボル。これらのシンボルは、LLVMのデッドコード削除を通じて保持され、クロージャコンパイラの実行後（「Module」上）でも、生成されたコードの外部からアクセスできるようになります。ここにリストされているネイティブシンボルには、_プレフィックスが必要です。

コマンドラインでこの設定が指定されていない場合、デフォルトでは、_main関数が暗黙的にエクスポートされます。STANDALONE_WASMモードでは、デフォルトのエクスポートは__startです（または、–no-entryが指定されている場合は__initialize）。

JSライブラリシンボルも、このリストに追加できます（先頭の$なし）。

デフォルト値: []

EXPORT_ALL¶

trueの場合、JSに存在するすべてのシンボルをModuleオブジェクトにエクスポートします。これは、どのシンボルが存在するかには影響しません。DCEを防止したり、リンクに何かを含めたりすることはありません。JSファイルに最終的に含まれるすべてのXに対して、Module['X'] = X;を実行するだけです。これは、動的リンクなどのために、JSライブラリ関数をModuleにエクスポートする場合に役立ちます。

デフォルト値：false

EXPORT_KEEPALIVE¶

trueの場合、JSに存在するシンボルをModuleオブジェクトにエクスポートします。Module['X'] = X;を実行するだけです。

デフォルト値：true

RETAIN_COMPILER_SETTINGS¶

これらの設定の値を記憶し、getCompilerSetting および emscripten_get_compiler_setting を通してアクセスできるようにします。何が保持されているかを確認するには、生成されたコードの compilerSettings を探してください。

デフォルト値：false

DEFAULT_LIBRARY_FUNCS_TO_INCLUDE¶

デフォルトで含める JS ライブラリ要素 (JS で実装された C 関数)。JS コンパイラで必ず含めたいものがある場合は、ここに追加してください。たとえば、C から emscripten_* C API 呼び出しを使用していないが、JS から呼び出したい場合は、ここに追加します。これは関数だけでなく、任意の JS ライブラリ要素のためのものであるため、名前は少し誤解を招く可能性があることに注意してください。たとえば、"$Browser" をこのリストに追加することで、Browser オブジェクトを含めることができます。

JS ライブラリシンボルを含めてエクスポートする場合は、DEFAULT_LIBRARY_FUNCS_TO_INCLUDE に追加することなく、EXPORTED_FUNCTIONS に追加するだけで十分です。

デフォルト値: []

INCLUDE_FULL_LIBRARY¶

生成されたコードで使用される関数と DEFAULT_LIBRARY_FUNCS_TO_INCLUDE の合計の代わりに、すべての JS ライブラリ関数を含めます。これは、メインモジュールで使用されていないランタイムライブラリ関数を利用するモジュールを動的にロード (つまり dlopen) する場合に必要です。これは js ライブラリにのみ適用され、C には適用されないことに注意してください。必要なすべての C ライブラリを含めるには、メインファイルが必要です。たとえば、モジュールが malloc または new を使用する場合は、モジュールで使用するために、メインファイルでもそれらを使用する必要があります。

デフォルト値：false

RELOCATABLE¶

1 に設定すると、LLVM バックエンドから再配置可能なコードを出力します。グローバル変数と関数ポインタの両方がすべてオフセット (それぞれ gb と fp) されます。SIDE_MODULE または MAIN_MODULE に対して自動的に設定されます。

注記

リンクとコンパイルの両方で適用可能

デフォルト値：false

MAIN_MODULE¶

メインモジュールとは、ランタイム時にサイドモジュールにリンクできるようにコンパイルされたファイルです。

1: 通常のメインモジュール。
2: DCE されたメインモジュール。通常、デッドコードを削除します。サイドモジュールがメインモジュールから何かを必要とする場合は、それが存続するようにする必要があります。

注記

リンクとコンパイルの両方で適用可能

デフォルト値：0

SIDE_MODULE¶

MAIN_MODULE に対応します (モード 1 および 2 もサポートしています)。

注記

リンクとコンパイルの両方で適用可能

デフォルト値：0

RUNTIME_LINKED_LIBS¶

非推奨です。代わりに、コマンドラインで共有ライブラリを直接リストしてください。

注記

この設定は非推奨です

デフォルト値: []

BUILD_AS_WORKER¶

1 に設定すると、これはワーカーライブラリであり、ワーカーで実行される特別な種類のライブラリです。emscripten.h を参照してください。

デフォルト値：false

PROXY_TO_WORKER¶

1 に設定すると、プロジェクトをワーカーで実行される js ファイルにビルドし、そこへの入出力をプロキシする html ファイルを生成します。

デフォルト値：false

PROXY_TO_WORKER_FILENAME¶

設定されている場合、メインスレッドがロードするスクリプトファイル名。プロジェクトが emscripten で生成されたメインスクリプトをすぐに実行せず、事前にいくつかのセットアップを行う場合に便利です。

デフォルト値: ''

PROXY_TO_PTHREAD¶

1 に設定すると、pthread_create() を呼び出して pthread でアプリケーションの main() を実行する、実際の main() との間にある小さなスタブ main() にコンパイルされます。これは、アプリケーションが希望すれば手動でも実行できます。このオプションは便宜上提供されています。

main() が実行される pthread は、スタックサイズがメインスレッドが通常持つサイズと同じであるという点が 1 つ異なるだけで、他のすべての点で通常の pthread です。つまり、STACK_SIZE です。これにより、main() が常に同じ量のスタックを取得して、PROXY_TO_PTHREAD モードと非 PROXY_TO_PTHREAD モードを簡単に切り替えることができます。

OFFSCREENCANVAS_SUPPORT が有効になっている場合、存在する場合は Module['canvas'] をプロキシします。これは、このブラウザのメインスレッドがそのスレッドで発生する唯一の pthread_create 呼び出しを行うため、そこからキャンバスを転送する唯一のチャンスであるため、発生する必要があります。

デフォルト値：false

LINKABLE¶

1 に設定すると、このファイルは、共有ライブラリとして、または共有ライブラリを呼び出すメインファイルとして、他のファイルとリンクできます。それを有効にするために、すべてのシンボルを内部化して未使用のものを削除することはありません。つまり、リンク先の別のモジュールで使用される可能性のある未使用の関数とグローバル変数は削除しません。

MAIN_MODULE と SIDE_MODULE はどちらもこれを意味するため、通常、これを明示的に設定する必要はありません。MAIN_MODULE と SIDE_MODULE モード 2 はこれを設定しないため、それらに対して通常の DCE を実行し、その場合はエクスポートを使用して関連するものを自分で存続させる必要があることに注意してください。

デフォルト値：false

STRICT¶

Emscripten の「厳密な」ビルドモード: 非推奨のビルドオプションのサポートを削除します。環境変数 EMCC_STRICT=1 を設定するか、-sSTRICT を渡して、コードベースが前方互換性のある方法で適切にビルドされることをテストします。これにより有効になる変更

C 定義 EMSCRIPTEN は定義されていません (__EMSCRIPTEN__ は常に定義されており、使用するのが正しいものです)。

STRICT_JS が有効になっています。

IGNORE_MISSING_MAIN が無効になっています。

AUTO_JS_LIBRARIES が無効になっています。

AUTO_NATIVE_LIBRARIES が無効になっています。

DEFAULT_TO_CXX が無効になっています。

USE_GLFW はデフォルトで 2 ではなく 0 に設定されています。

ALLOW_UNIMPLEMENTED_SYSCALLS が無効になっています。

INCOMING_MODULE_JS_API はデフォルトで空に設定されています。

注記

デフォルトでは、すべてのコードをそのまま出力 .js ファイルに出力します。つまり、Web ページのスクリプトタグでそれをロードすると、グローバルスコープが使用されます。MODULARIZE を設定すると、代わりに、プロミスを返す関数でラップされたコードが出力されます。プロミスは、コンパイル済みコードを実行しても安全な場合にモジュールインスタンスで解決されます。これは onRuntimeInitialized コールバックに似ています。MODULARIZE を使用している場合、onRuntimeInitialized コールバックを使用する必要はありません。

(WASM_ASYNC_COMPILATION がオフの場合、つまりコンパイルが同期の場合、プロミスを返すのは意味がないため、代わりに、すぐに使用できるモジュールオブジェクト自体が返されます。)

関数のデフォルト名は Module ですが、EXPORT_NAME オプションを使用して変更できます。ファクトリ関数には、たとえば createModule のように、より一般的な名前に変更することをお勧めします。

ファクトリ関数は次のように使用します

const module = await EXPORT_NAME();

または

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

ファクトリー関数は、モジュールインスタンスのデフォルト値を持つオブジェクトを1つパラメータとして受け取ります。

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

括弧に注意してください - モジュールをインスタンス化するために、EXPORT_NAMEを呼び出しています。これにより、モジュールの複数のインスタンスを作成できます。

MODULARIZEモードでは、デフォルト値のためにグローバルなModuleオブジェクトを探すことはないことに注意してください。デフォルト値はファクトリー関数のパラメータとして渡す必要があります。

MINIMAL_RUNTIMEモードで提供されるデフォルトの.htmlシェルファイルは、ページ上でアプリケーションを実行するために、シングルトンインスタンスを自動的に作成します。（これは、前述のPromise APIを使用せずに実行するため、emccに.html出力を生成するように指示した場合、Promiseのコードは.jsファイルにも出力されないことに注意してください。）従来のランタイムモードで提供されるデフォルトの.htmlシェルファイルは、MODULARIZE=0モードとのみ互換性があるため、従来のランタイムでビルドする場合は、MODULARIZE=1でビルドするときに、インスタンス化を実行する独自のhtmlシェルファイルを提供する必要があります。（詳細については、https://github.com/emscripten-core/emscripten/issues/7950を参照してください）

–pre-jsまたは–post-jsファイルを追加すると、それらは最適化のために、他の生成されたコードとともにファクトリー関数内に含まれます。

ファクトリー関数を含む、生成されたコードの外側にコードを含めたい場合は、–extern-pre-jsまたは–extern-post-jsを使用できます。–pre-jsと–post-jsは、非MODULARIZEモードではそれを行う可能性がありますが、それらの意図された使用法は、コードの残りの部分で最適化されるコードを追加することであり、より良いデッドコード除去と最小化を可能にします。

デフォルト値：false

EXPORT_ES6¶

UMDエクスポートではなく、ES6モジュールエクスポートを使用してエクスポートします。ES6エクスポートではMODULARIZEを有効にする必要があり、まだ設定されていない場合は暗黙的に有効になります。

出力サフィックスが「mjs」に設定されている場合、これは暗黙的に有効になります。

デフォルト値：false

USE_ES6_IMPORT_META¶

ES6モジュールの相対インポート機能「import.meta.url」を使用して、WASMモジュールパスを自動検出します。古いブラウザ/ツールチェーンではサポートされない場合があります。Node.jsがターゲット（-sENVIRONMENT = * node *）の場合、この設定は無効にできません。

デフォルト値：true

EXPORT_NAME¶

標準化されたモジュールローディングシステムがない環境（ブラウザやSMシェルなど）のために、モジュールをエクスポートするグローバル変数。

デフォルト値：'Module'

DYNAMIC_EXECUTION¶

0に設定すると、eval()とnew Function()を出力しません。これにより、一部の機能が無効になります（使用しようとするとランタイムエラーが発生します）が、動的なコード実行を許可しない場所（Chromeパッケージアプリ、特権付きFirefoxアプリなど）で出力されたコードを受け入れられるようにします。特権付きまたは認定された実行環境をターゲットとするEmscriptenアプリケーションを開発する際に、このフラグを渡します。詳細については、Firefoxのコンテンツセキュリティポリシー（CSP）のWebページを参照してください：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src、特に「unsafe-eval」および「wasm-unsafe-eval」ポリシーを参照してください。

このフラグが設定されている場合、次の機能（リンカーフラグ）は使用できません。

RELOCATABLE：関数loadDynamicLibraryはeval()を必要とします。

また、一部の機能は、必要な場合に遅いコードパスにフォールバックする場合があります。Embind：高速化のためにeval()を使用して関数をJITコンパイルします。

さらに、DYNAMIC_EXECUTION=0が設定されている場合、次のEmscriptenランタイム関数は使用できず、それらを呼び出そうとすると例外がスローされます。

emscripten_run_script(),
emscripten_run_script_int(),
emscripten_run_script_string(),
dlopen(),
関数ccall()およびcwrap()は引き続き使用できますが、それらは事前にModuleオブジェクトでエクスポートされた関数のみを呼び出すことができるように制限されています。

WASM_ASYNC_COMPILATION¶

wasmを非同期にコンパイルするかどうか。これはより効率的で、メインスレッドをブロックしません。現在、Chromeで実行するには、最小のモジュールを除くすべてでこれが必要です。

（このオプションは以前はBINARYEN_ASYNC_COMPILATIONと呼ばれていました）

デフォルト値：true

DYNCALLS¶

1に設定すると、dynCall()およびdynCall_sig() APIが呼び出し元で利用可能になります。

デフォルト値：false

WASM_BIGINT¶

JavaScript BigIntとのWebAssembly統合。有効にすると、wasm VMはi64が使用される場所でBigIntを使用するため、i64をi32のペアに合法化する必要がなくなります。WASM_BIGINTが存在する場合、BigIntをサポートする最小バージョンにデフォルトの最小サポートブラウザバージョンが増加します。

デフォルト値：false

EMIT_PRODUCERS_SECTION¶

WebAssemblyは、コンパイラとツールが自分自身を注釈できる「プロデューサーセクション」を定義しており、LLVMはデフォルトでこれをエミットします。Emscriptenはコードサイズを増やすため、また、一部のユーザーはプライバシーまたはセキュリティ上の理由から、ツールに関する情報をビルドに含めたくない場合があるため、それを削除してないようにします。詳細については、https://github.com/WebAssembly/tool-conventions/issues/93を参照してください。

SDL2_image でサポートする形式。有効な値: bmp, gif, lbm, pcx, png, pnm, tga, xcf, xpm, xv

デフォルト値: []

SDL2_MIXER_FORMATS¶

SDL2_mixer でサポートする形式。有効な値: ogg, mp3, mod, mid

デフォルト値: ["ogg"]

USE_SQLITE3¶

1 = emscripten-ports から sqlite3 を使用します。代替構文: –use-port=sqlite3

注記

通常、アプリケーションはプールが空の場合でも新しいスレッドを作成できます。アプリケーションが pthread_join またはその他のブロッキングプリミティブを介してスレッドをブロックしようとする前に JS イベントループにブレイクアウトすると、追加の Worker が作成され、スレッドコールバックが実行されます。ただし、イベントループにブレイクアウトするには、コードを Web に適応させるためのカスタム変更が必要であり、既製のアプリでは機能しないものです。変更を加えないこれらのアプリは、デッドロックになる可能性が最も高くなります。この設定により、デッドロックのリスクを冒す代わりに、少なくとも C / C++ 側から正常に処理できるランタイム EAGAIN エラーが発生するようになります。値

0 - スレッドプールの枯渇に関する警告を無効にする
1 - スレッドプールの枯渇に関する警告を有効にする (デフォルト)
2 - スレッドプールの枯渇を重大なエラーにする

インポートの呼び出しなど、コンパイル時に評価できないものが見つかると、これは停止します。このオプションを使用して実行すると、何が評価され、どこで停止したかを示すログが表示されます。

この最適化により、コードサイズが縮小または増加する可能性があります。たとえば、少量のコードでメモリ内で多くの変更が生成される場合、全体的なサイズが増加する可能性があります。

LLVM の GlobalOpt は、ほぼこの操作を行います。LLVM IR がそのロジックで評価するには複雑すぎない単純なケースではそうですが、libc++ iostream ctor などには十分な能力がありません。LLVM IR レベルでは実行するのが難しいだけです。LLVM IR は複雑であり、ますます複雑になっているため、これには GlobalOpt が完全なインタープリターと、LLVM IR グローバルオブジェクトに書き戻す方法が必要になります。しかし、wasm レベルでは、すべてが単純な低レベルに下げられており、バイトを配列に書き込むだけでよいため、これは簡単に実行できます。LLVM のもう 1 つの問題は、さらにコードをリンクしないことを認識していないため、優先順位が最も低い ctor のみを最適化しようとします (ダイナミックリンクが有効になっているかどうかを明示的に知っている間)。

値 2 に設定すると、ctor の評価中に受信される入力がないという、いくつかの「安全でない」仮定も行われます。つまり、main() への引数を無視し、環境変数が読み取り可能ではないと仮定します。これにより、より多くのプログラムを最適化できますが、プログラムがこれらの機能に依存していないことを確認する必要があります。argc の値をチェックするだけでも問題が発生する可能性があります。

デフォルト値：0

TEXTDECODER¶

有効な場合、文字列マーシャリングに JavaScript TextDecoder API を使用します。デフォルトで有効になっている場合は、これを 0 に設定して無効にします。2 に設定した場合、TextDecoder が存在し使用可能であると仮定し、TextDecoder が存在しない場合にフォールバックするための JS コードを出力しません。シングルスレッドの -Oz ビルドモードでは、TEXTDECODER はコードサイズを節約するためにデフォルトで値 == 2 になります。

デフォルト値：1

EMBIND_STD_STRING_IS_UTF8¶

Embind 固有: 有効にした場合、std::string バインディングで UTF-8 エンコードされたデータを想定します。バイナリデータ転送をサポートするには、これを無効にします。

デフォルト値：true

EMBIND_AOT¶

Embind 固有: 有効にすると、Embind の JavaScript インボーカ関数をコンパイル時に生成し、JS 出力ファイルに含めます。DYNAMIC_EXECUTION=0 と組み合わせて使用すると、エクスポートされたバインディングは DYNAMIC_EXECUTION=1 モードと同じくらい高速になりますが、eval() は必要ありません。ただし、バインディングが多い場合、JS 出力サイズが大きくなる可能性があります。

デフォルト値：false

OFFSCREENCANVAS_SUPPORT¶

1 に設定すると、canvas を pthread に転送したり、WebGL コンテキストを canvas 内に作成したり、GL コンテキストの明示的なスワップ制御を有効にしたりするサポートが有効になります。これには、OffscreenCanvas 仕様に対するブラウザのサポートが必要です。

デフォルト値：false

OFFSCREENCANVASES_TO_PTHREAD¶

PROXY_TO_PTHREAD を OFFSCREENCANVAS_SUPPORT と共に使用している場合は、プログラムの起動時に pthread にプロキシする canvas の CSS ID セレクタのカンマ区切りリストをここに指定します (例: '#canvas1, #canvas2')。

デフォルト値: “#canvas”

OFFSCREEN_FRAMEBUFFER¶

1 に設定すると、WebGL コンテキストがオフスクリーンレンダーターゲットにレンダリングするサポートが有効になり、イベントコールバックを終了するとレンダリングされたコンテンツを画面に表示するために自動的に「フリップ」を実行する WebGL の暗黙的なスワップ動作を回避します。Emscripten GL コンテキストでオフスクリーンフレームバッファが有効になっている場合、単一のフレームを複数のイベントコールバックから合成でき、レンダリングされたコンテンツを画面に表示するためにスワップ関数 emscripten_webgl_commit_frame() が明示的に呼び出されます。

オフスクリーンキャンバス機能は、明示的な GL フレームスワップのサポートも有効にします。また、-sOFFSCREEN_FRAMEBUFFER 機能を使用すると、ブラウザでオフスクリーンキャンバスのサポートがない場合でも、パフォーマンスとレイテンシーが多少犠牲になる代わりに、複数スレッドでの WebGL へのアクセスをポリフィルできます。オフスクリーンキャンバスとオフスクリーンフレームバッファのサポートは同時に有効にすることができ、利用可能な場合はオフスクリーンキャンバスを利用し、それ以外の場合はオフスクリーンフレームバッファにフォールバックすることができます。

デフォルト値：false

FETCH_SUPPORT_INDEXEDDB¶

ゼロ以外の場合、Fetch API は IndexedDB へのバックアップをサポートします。0 の場合、IndexedDB は使用されません。ターゲットアプリケーションで IndexedDB のサポートが不要な場合は、数 k バイトを節約するために 0 に設定します。

デフォルト値：true

FETCH_DEBUG¶

ゼロ以外の場合、library_fetch.js にデバッグ情報が出力されます。

デフォルト値：false

FETCH¶

ゼロ以外の場合、emscripten_fetch API を有効にします。

デフォルト値：false

WASMFS¶

注意 [WIP]: 実験的な機能です。ご自身の責任で使用してください。これは最終的に現在の JS ファイルシステムの実装を置き換えます。1 に設定すると、新しいファイルシステムの実装を使用します。

注記

これは実験的な設定です

デフォルト値：false

SINGLE_FILE¶

1 に設定すると、すべてのサブリソースが base64 文字列リテラルとして出力ファイルに埋め込まれます。埋め込まれたサブリソースには、wasm、asm.js、静的メモリ初期化コードなどが含まれる可能性があります (ただし、これらに限定されません)。

このオプションに依存するコードを使用する場合、コンテンツセキュリティポリシーを更新する必要がある場合があります。具体的には、asm.js を埋め込むには、script-src ディレクティブで 'unsafe-inline' を許可する必要があり、Worker を使用するには、child-src ディレクティブで blob: を許可する必要があります。コンテンツセキュリティポリシーを使用していない場合、または CSP ヘッダーに script-src または child-src のいずれも含まれていない場合は、この警告を無視しても安全です。

デフォルト値：false

AUTO_JS_LIBRARIES¶

1 に設定すると、すべての JS ライブラリがリンク時に自動的に利用可能になります。これは STRICT モード (または MINIMAL_RUNTIME) では 0 に設定されます。つまり、library_foo.js のライブラリ関数にアクセスするには、リンク時に -lfoo.js を明示的に指定する必要があります。

デフォルト値：true

AUTO_NATIVE_LIBRARIES¶

AUTO_JS_LIBRARIES と同様ですが、libgl、libal、libhtml5 などのネイティブライブラリ用です。これを無効にする場合は、-lhtml5 などを明示的に追加する必要があり、さらに最初に embuilder を使用してライブラリをビルドする必要があります。

デフォルト値：true

MIN_FIREFOX_VERSION¶

ターゲットとする Firefox の最も古いメジャーバージョンを指定します。つまり、MIN_FIREFOX_VERSION >= のすべての Firefox バージョンで動作することが望まれます。MIN_FIREFOX_VERSION=majorVersion を渡して、majorVersion より古い Firefox バージョンのサポートを削除します。Firefox 79 は 2020-07-28 にリリースされました。MAX_INT (0x7FFFFFFF、または -1) は、ターゲットがサポートされていないことを指定します。サポートされている最小値は、2014-12-01 にリリースされた 34 です。

デフォルト値: 79

MIN_SAFARI_VERSION¶

ターゲットとするデスクトップ版 Safari の最も古いバージョンを指定します。バージョンは MMmmVV でエンコードされます (例: 70101 は Safari 7.1.1 を示します)。Safari 14.1.0 は 2021 年 4 月 26 日にリリースされ、macOS 11.0 Big Sur および iOS 14.5 にバンドルされました。前のデフォルトである Safari 12.0.0 は、2018 年 9 月 17 日にリリースされ、macOS 10.14.0 Mojave にバンドルされました。注意: Emscripten は iOS 9.3.5 以前 (つまり、iPhone 4s、iPad 2、iPad 3、iPad Mini 1、Pod Touch 5 以前) で動作するコードを生成できません。詳細については、https://github.com/emscripten-core/emscripten/pull/7191 を参照してください。MAX_INT (0x7FFFFFFF、または -1) は、ターゲットがサポートされていないことを指定します。サポートされている最小値は、2015 年にリリースされた 90000 です。

デフォルト値: 140100

MIN_CHROME_VERSION¶

Chrome の最も古いバージョンを指定します。例: Chrome 57 以前のサポートを削除するには、-sMIN_CHROME_VERSION=58 を渡します。この設定は、Chrome とバージョン番号を共有する最新の Chromium ベースの Edge にも適用されます。Chrome 85 は 2020-08-25 にリリースされました。MAX_INT (0x7FFFFFFF、または -1) は、ターゲットがサポートされていないことを指定します。サポートされている最小値は、2014-01-04 にリリースされた 32 です。

デフォルト値: 85

MIN_NODE_VERSION¶

生成されたコードのターゲットとする最小の Node バージョンを指定します。これは、emscripten コンパイラの実行に必要な最小バージョンとは異なります。このバージョンは、現在の Ubuntu TLS 20.04 (Focal) に対応しています。バージョンは MMmmVV でエンコードされます (例: 181401 は Node 18.14.01 を示します)。サポートされている最小値は 2020-02-05 にリリースされた 101900 です。

デフォルト値: 160000

SUPPORT_ERRNO¶

JS ライブラリコードから errno を設定することをサポートするかどうか。MINIMAL_RUNTIME ビルドでは、このオプションはデフォルトで 0 になります。

注記

この設定は非推奨です

デフォルト値：true

MINIMAL_RUNTIME¶

true の場合、POSIX 機能、Module、preRun/preInit など、Emscripten 組み込みの XHR ロード、または library_browser.js を使用しない、最小サイズのランタイムを使用します。可能な限り最小のコードサイズをターゲットにするには、この設定を有効にします。さらに多くのコードサイズ最適化を有効にするには、MINIMAL_RUNTIME=2 を設定します。これらのオプションはかなりハッキーで、Closure やビルドシステムの他の部分の制限を回避するため、生成されたすべてのプログラムで動作するとは限りません (ただし、非常に小さいプログラムには役立ちます)。

デフォルト値：false

SIGNATURE_CONVERSIONS¶

ポインタ引数を取るか返すシグネチャ変換でラップするユーザー定義関数。MEMORY64=1 ビルドのみに影響します。詳細については、emscripten.py の create_pointer_conversion_wrappers を参照してください。ポインタ以外の引数には _ を、ポインタ/i53 引数には p を、オプションのポインタ/i53 値には P を使用します。使用例 -sSIGNATURE_CONVERSIONS=someFunction:_p,anotherFunction:p

デフォルト値: []