私は最近、emscripten c/C++ javascriptコンパイラで作業を始めました。ソースからコンパイラをビルドしようとすると、特定のバージョンのclangが自動的に見つかりました。特定のclangバージョン（emscriptenのバージョンのようなもの）の存在の動機は何ですか？
今まで、別のバージョンのコンパイラが存在する理由はどこにも見つかりませんでした。あなたがllvmの仕様に従えば、すべてのバックエンドがあらゆるフロントエンドからの入力を得ることができ、両方に同じllvmバージョンを使用するという印象を受けました。私は、特定のコマンドラインオプションを使用するためにこのアプローチを使用することができますが、代わりにジョブ全体を再構築し、そのジョブを実行してドットを接続するというスクリプトでは利点がないと考えることができます。
バックエンドを実装するだけではなく、特定のclangビルドを実行する利点は何ですか？
バックエンドの実装は、WebAssemblyの場合とまったく同じです。したがって、EmscriptenはWebAssemblyとasm.jsの両方でバックエンドを使用できるようになります。
LLVMでの十分な経験がなく、不確かな実験としてEmscriptenおよびPNaClを開始した。著者らは、LLVMの制約を満たすのではなく、合理的な方法で自分のことを書く方が簡単でした。これらの作業は通常通り行われていますが、それらの実験は完全に消滅していません...しかし、WebAssemblyではすべてのことを正しく行う必要があります。
LLVMの制約は完全に賢明です。高いコード品質を維持し、メンテナンスの負担をかけずに、コードのレイヤー間の不要な依存関係を回避します。それはLLVMが成功することを可能にします。新しいバックエンドを受け入れるとき、LLVMは新しいバックエンドに負担をかけず、より良いものにしたい、あるいは孤立して存在するバックエンドを持たない、（video）LLVMは、NaCl's x86 sandboxesが依存しているx86命令のバンドルや、NaClがx86-64 sandboxに依存するx32、PNaClとEmscriptenの両方のために、x32でどのようにサポートされているのかをよくサポートしていませんでしたその時点でvirtual ISAsがサポートされている可能性があります。私はあまり単純化していますが、他の多くの要因がこれらの決定に入りました。
PNaClは、LLVMをPNaClの用途に適したコードレビューに参加している上流のLLVMとPNaCl開発者にもかかわらず、依然としてかなりの変更（LLVMとclangフォーク）を持っています。これらの変更は、NaClサンドボックス処理に必要なバックエンドの変更（subzeroが置き換えようとしている）、bitcode "simplification" passesのバックエンドのために "LLVMのやり方"（そしてEmscriptenが使用する）上流にある。
Emscriptenは、以前のアプローチの代わりにfastcompに移動したときに、実質的なアプローチの変更を確認しました。
これらのコンパイラは、C++標準ライブラリ（libC++/libC++ abi、ほとんど変更なし、libstdC++をサポートするために使用されるPNaCl）、C標準ライブラリ（どちらもmusl、コンパイラランタイム（コンパイラ-rt）、リンカ、SDL（Emscriptenの一部、webportsのPNaClの一部）などの一般的なユーザライブラリがあります。
どちらの場合でも、Emscriptenの変更はPNaClよりもはるかに簡単ですが、どちらの場合でもコンパイラはtrunk LLVM準標準にリベースされます。フォークを維持するには莫大なコストがかかります！