ポータビリティ
プラットフォームとコンパイラ
以下の表は、Duktapeが動作することが確認されているプラットフォームとコンパイラをまとめたもので、必要に応じて移植性に関する注意事項も記載しています。これは、サポート/非サポート・プラットフォームの網羅的なリストではなく、むしろ、動作することが知られているもの（および動作しないもの）のリストです。プラットフォームやコンパイラー固有の問題については、表の下の方で詳しく説明しています。
| Operating system | Compiler | Processor | Notes |
|---|---|---|---|
| Linux | GCC | x86 | 既知の問題はありません。 |
| Linux | GCC | x64 | 既知の問題はありません。 |
| Linux | GCC | x32 | 既知の問題はありません。-mx32を使用してください。 |
| Linux | GCC | ARM | 既知の問題はありません。 |
| Linux | GCC | MIPS | 既知の問題はありません。 |
| Linux | GCC | SuperH | 既知の問題はありません。 |
| Linux | GCC | SPARC | 既知の問題はありません。 |
| Linux | Clang | x86 | 既知の問題はありません。 |
| Linux | Clang | x64 | 既知の問題はありません。 |
| Linux | Clang | ARM | 既知の問題はありません。 |
| Linux | Clang | MIPS | 既知の問題はありません。 |
| Linux | TCC | x64 | 符号の問題はゼロ（後述）。 |
| FreeBSD | Clang | x86 | 64-bit FreeBSD上のclang 3.3、-m32、packed duk_tvalでのエイリアシング問題(下記参照)。 |
| FreeBSD | Clang | x64 | 既知の問題はありません。 |
| NetBSD | GCC | x86 | 既知の問題はありません(NetBSD 6.0)。NetBSD では pow() 関数の非互換性がありますが、回避策があります。 |
| OpenBSD | GCC | x86 | 既知の問題はありません(OpenBSD 5.4)。 |
| Windows | MinGW | x86 | -std=c99 を推奨、ISO 8601 日付形式のみサポート (プラットフォーム固有の形式はなし)。 |
| Windows | MinGW-w64 | x64 | -m64、-std=c99 を推奨、ISO 8601 日付形式のみをサポート (プラットフォーム固有の形式はなし)。 |
| Windows | MSVC (Visual Studio Express 2010) | x86 | ISO 8601 日付形式のみサポート (プラットフォーム固有の形式はありません)。Wp64が有効な場合、無害な警告が表示されます。 |
| Windows | MSVC (Visual Studio Express 2013 for Windows Desktop) | x64 | ISO 8601の日付フォーマットのみサポート（プラットフォーム固有のフォーマットはありません）。 |
| Windows | MSVC (Visual Studio 2010) | x64 | ISO 8601 日付形式のみサポート (プラットフォーム固有の形式はありません)。Duktape 0.10.0 では、DUK_OPT_NO_PACKED_TVAL を明示的に指定する必要があるかもしれません。 |
| Android | GCC (Android NDK) | ARM | 少なくともNDKのいくつかのバージョンでは、-std=c99が必要です。 |
| OSX | Clang | x64 | OSX 10.9.2、XCodeでテスト済み。 |
| Darwin | GCC | x86 | 既知の問題はありません。 |
| QNX | GCC | x86 | -std=c99 を推奨します。x86 以外のアーキテクチャでも動作するはずです。 |
| AmigaOS | VBCC | M68K | プリプロセッサの定義が必要で、日時の分解能は秒単位に制限されます。 |
| TOS (Atari ST) | VBCC | M68K | プリプロセッサの定義が必要で、日時の分解能は秒単位に制限されます。 |
| RISC OS | GCC | ARM | 既知の問題はありません。 |
| Emscripten | Emscripten | n/a | 追加オプションが必要です。少なくともV8/NodeJsは動作します。 |
| Adobe Flash Runtime | CrossBridge (GCC-4.2 with Flash backend) | n/a | -std=c99を推奨、32ビットJavaを実行する場合は、-jvmopt=-Xmx1Gが必要な場合があります。64ビットWindows 7上のCrossBridge 1.0.1でテスト済み。 |
| pNaCl | clang | n/a | 既知の問題はありません。 |
| Linux | BCC (Bruce's C compiler) | i386 | -3と-ansiが必要。コンパイルはできるがリンクはしない。移植性のテストに便利な古いコンパイラです(例えば16ビットint型)。 |
Clang
FreeBSD 上の Clang 3.3 では、-m32 を使用したときに Duktape が pack された duk_tval 値表現型を使用した場合に、(少なくとも) エイリアスの問題が発生します。この問題は、DUK_OPT_NO_PACKED_TVAL を定義して、packed value type を無効にすることにより回避できます。この問題は全てのclangのバージョンで発生するわけではありません。Duktapeのセルフテストはこの問題をカバーしています（コンパイル時にDUK_OPT_SELF_TESTSを定義してください。内部テストファイルclang_aliasing.cを参照してください。
MSVC
Wp64 (64ビット移植性の問題の検出) オプションは、32ビットコードをコンパイルする際に無害なコンパイル警告を発生させます。
duk_api.c(2419): warning C4311: 'type cast' : pointer truncation from 'duk_hstring *' to 'duk_uint32_t'
この警告は、Duktapeが32ビット・ポインタを内部値表現で使われる32ビット整数にキャストしたために発生します。これらのキャストは64ビット環境では正しくなく、これは/Wp64オプションで報告されます。Duktapeが64ビット環境でコンパイルされた場合、これらのキャストを全く使用しない別の値表現が使用されるので、警告は適切ではありません。Wallを使ったコンパイルは、今のところクリーンではありません。
TCC
TCC にはゼロ記号の処理に問題があります。Duktape はほとんど動作しますが、ゼロ記号は正しく処理されません。これは ECMAScript に準拠しない結果となります。例えば、1/-0 は Infinity と評価され、-Infinity と評価されるはずのものではありません。
VBCC (AmigaOS / TOS)
VBCCは、OSやプロセッサの定義を提供しないようです。M68K AmigaOS または TOS 用にコンパイルするには、以下が必要です。
- 手動で__MC68K__を定義する。
- AMIGAか__TOS__を手動で定義する。
AmigaOSまたはTOSでVBCCを使用する場合、日付の分解能は完全な秒に制限されます。
Emscripten
emccオプションのセットが必要です。V8で実行した場合、以下が動作するようです。
- DEMSCRIPTEN: DuktapeがEmscriptenを検出するために必要な必須オプションです。このオプションがないと、DuktapeはEmscriptenが許可しないアラインド・アクセスを使用する可能性があります。この結果、奇妙で一貫性のない動作になり、Duktapeのセルフ・テストでは必ずしも検出されません。 -std=c99
- -O2 -メモリ・イット・ファイル 0
Dukweb は Emscripten を使ってコンパイルされているので、Duktape の git リポジトリをチェックして、Dukweb がどのようにコンパイルされているかを確認することもできます。
制限事項
- ポインターの小なり大なりの比較は、ポインターが符号なしであるかのように動作することが期待されます。これはいくつかのプラットフォームでは正しくありません。
- 2の補数符号付き演算が必要です。ANSI Cでは技術的に保証されていませんが、この前提が成立しない環境は非常に少ないです。
- float 型と double 型は IEEE の動作を仮定しています。これは、例えば gcc -ffast-math (https://gcc.gnu.org/wiki/FloatingPointMath を参照) がサポートされていないことを意味します。Duktapeは、IEEEのfloatとdoubleのメモリ表現も直接扱えます。
- Duktape は現在、EBCDIC プラットフォームなどでは動作しません。
トラブルシューティング
- 可能であれば C モードでコンパイルしてください。C++ コンパイルは現在動作していますが、C コンパイルほどポータブルではありません。
- 可能であれば C99 モードを有効にしてください (-std=c99 など)。C99を使わない場合の型検出は、C99を使う場合よりも信頼性が低くなります。Duktape はまた、C99/POSIX の (v)snprintf() に依存しています。MSVC にはフィルインがありますが、他の非C99プラットフォームでは、 DUK_SNPRINTF() と DUK_VSNPRINTF() をあなたの duk_config.h ヘッダーで手動定義しなければならない場合があります。
- Duktape をコンパイルしても正しく動作しないようであれば、 DUK_OPT_SELF_TESTS で自己テストを有効にしてください。セルフ・テストは、コンパイル時に捕捉できないコンパイラーやプラットフォームの問題を検出します。
- もし、ターゲット・プラットフォームが特定のアライメント要求を持っていて、Duktapeがプラットフォームを正しく自動検出しない場合、DUK_OPT_FORCE_ALIGN=4かDUK_OPT_FORCE_ALIGN=8を指定する必要があるかもしれません。アラインメント番号は、IEEEダブルや64ビット整数値に対して必要なアラインメントと一致させる必要があります。
- エンディアンの検出でコンパイルに失敗する場合、Duktapeはあなたのプラットフォーム特有のエンディアン・ヘッダを（まだ）サポートしていない可能性があります。そのようなヘッダは残念ながら標準化されていませんので、エンディアンの検出はカスタム・プラットフォームにおける一般的な（そして通常は些細な）移植性の問題です。DUK_OPT_FORCE_BYTEORDER を使用して、回避策としてエンディアンを強制的に検出します。もし、あなたのプラットフォームでエンディアンの検出がどのように機能すべきかを知っているなら、その問題についてメールを送るか、パッチを提供してください。
- 新しい/エキゾチックなプラットフォームにおけるもう1つの典型的な移植性の問題は、日付と時間を扱うためにいくつかのプラットフォーム固有の関数を必要とする組み込みの日付です。多くの場合、既存のDate関数で十分ですが、そうでない場合は、Duktapeの変更を必要としない外部の「Dateプロバイダ」を実装することができます（参考： datetime.rst.
- いくつかのエキゾチックなプラットフォームでは、doubleからinteger、integerからdoubleへのキャストが壊れており、例えば https://github.com/svaarala/duktape/issues/336 のような現象が発生します。Duktapeの内部では、いくつかの場所でキャストが使用されているため、現時点では簡単な回避策はありません。将来的には、このようなキャストにマクロを使用することで、プラットフォームに依存した方法でキャストを修正し、duk_config.hを編集して動作するキャスト・マクロを提供できるようにすることが可能です。
- Duktape 1.3以降、移植性に関連するほとんど全てのincludeとdefineは、外部のduk_config.hヘッダにあり、異国のプラットフォームに合うように自由に変更することができます。