存在特定 clang 版本（如 emscripten 版本）的动机是什么？
what is the motivation for the existence of specific clang versions (like the emscripten one)?
我最近开始使用 emscripten c/c++ 到 javascript 编译器做一些工作，并且在尝试从源代码构建编译器时，我看到它本身有一个特定版本的 clang。
直到现在，我在任何地方都找不到有单独版本的编译器的原因。我的印象是，如果您遵循 llvm 规范并为两者使用相同的 llvm 版本，则每个后端都可以从每个前端获得输入。我可以想象，人们可以使用这种方法来使用特定的命令行选项，但看不到重建整个东西的优势，而是通过脚本来完成这项工作并连接点。
那么，与仅实施后端相比，执行特定的 clang 构建到底有什么优势？
实现后端正是我们为 WebAssembly 所做的，Emscripten 最终将能够将该后端用于 WebAssembly 和 asm.js。
Emscripten 和 PNaCl 是作为不确定的实验开始的，没有足够的 LLVM 经验。与满足 LLVM 的约束相比，作者以他们认为合理的方式编写自己的东西更容易。正如这些事情通常发生的那样，那些实验并没有完全消失......但随着时间的推移，WebAssembly 应该会让一切都变得正确。
LLVM 的约束是完全明智的：保持高代码质量，不增加维护负担，避免在代码层之间产生不必要的依赖。这使得 LLVM 能够成功：当它接受新的后端时，LLVM 希望作为一个整体变得更好，而不是被新的后端所负担，或者有一个孤立存在的后端，或者变得无人维护。其他约束更具历史意义：当时可以支持 PNaCl started in ~2010 (video) LLVM didn't have great support for x86 instruction bundling which NaCl's x86 sandboxes relies on, or for x32 which NaCl relies on for its x86-64 sandbox, and both for PNaCl and Emscripten it wasn't clear how virtual ISAs。我过于简单化了，许多其他因素影响了这些决定，我相信如果今天做出这些决定，事情会有所不同。
PNaCl 仍然有实质性的变化（LLVM and clang forks), despite many of them making it to upstream LLVM and PNaCl developers participating in code reviews which made LLVM friendlier for PNaCl's usecases. These changes live in three categories: backend changes necessary for NaCl sandboxing (which subzero intends to replace), bitcode "simplification" passes 代表完成的后端 "the LLVM way"（Emscripten 使用），以及其他随机变化，其中许多可以上游。
Emscripten 在转向 fastcomp 而不是以前的方法时看到了实质性的方法变化。
注意，除了LLVM和clang之外还有很多：这些编译器还依赖C++标准库（都有libc++/libc++abi，大部分没变，PNaCl用来支持libstdc++），C标准库（都有musl , PNaCl 也有 newlib, bionic, 某种形式的 glibc), 编译器运行时 (compiler-rt), 连接器, 和一般用户库比如 SDL (Emscripten 的一部分, 和 for PNaCl in webports).
在这两种情况下，编译器都会半频繁地重新设置基准以主干 LLVM，尽管 Emscripten 的更改比 PNaCl 的更改更容易重新设置基准。维护分叉的成本很高！
我最近开始使用 emscripten c/c++ 到 javascript 编译器做一些工作，并且在尝试从源代码构建编译器时，我看到它本身有一个特定版本的 clang。
直到现在，我在任何地方都找不到有单独版本的编译器的原因。我的印象是，如果您遵循 llvm 规范并为两者使用相同的 llvm 版本，则每个后端都可以从每个前端获得输入。我可以想象，人们可以使用这种方法来使用特定的命令行选项，但看不到重建整个东西的优势，而是通过脚本来完成这项工作并连接点。
那么，与仅实施后端相比，执行特定的 clang 构建到底有什么优势？
实现后端正是我们为 WebAssembly 所做的，Emscripten 最终将能够将该后端用于 WebAssembly 和 asm.js。
Emscripten 和 PNaCl 是作为不确定的实验开始的，没有足够的 LLVM 经验。与满足 LLVM 的约束相比，作者以他们认为合理的方式编写自己的东西更容易。正如这些事情通常发生的那样，那些实验并没有完全消失......但随着时间的推移，WebAssembly 应该会让一切都变得正确。
LLVM 的约束是完全明智的：保持高代码质量，不增加维护负担，避免在代码层之间产生不必要的依赖。这使得 LLVM 能够成功：当它接受新的后端时，LLVM 希望作为一个整体变得更好，而不是被新的后端所负担，或者有一个孤立存在的后端，或者变得无人维护。其他约束更具历史意义：当时可以支持 PNaCl started in ~2010 (video) LLVM didn't have great support for x86 instruction bundling which NaCl's x86 sandboxes relies on, or for x32 which NaCl relies on for its x86-64 sandbox, and both for PNaCl and Emscripten it wasn't clear how virtual ISAs。我过于简单化了，许多其他因素影响了这些决定，我相信如果今天做出这些决定，事情会有所不同。
PNaCl 仍然有实质性的变化（LLVM and clang forks), despite many of them making it to upstream LLVM and PNaCl developers participating in code reviews which made LLVM friendlier for PNaCl's usecases. These changes live in three categories: backend changes necessary for NaCl sandboxing (which subzero intends to replace), bitcode "simplification" passes 代表完成的后端 "the LLVM way"（Emscripten 使用），以及其他随机变化，其中许多可以上游。
Emscripten 在转向 fastcomp 而不是以前的方法时看到了实质性的方法变化。
注意，除了LLVM和clang之外还有很多：这些编译器还依赖C++标准库（都有libc++/libc++abi，大部分没变，PNaCl用来支持libstdc++），C标准库（都有musl , PNaCl 也有 newlib, bionic, 某种形式的 glibc), 编译器运行时 (compiler-rt), 连接器, 和一般用户库比如 SDL (Emscripten 的一部分, 和 for PNaCl in webports).
在这两种情况下，编译器都会半频繁地重新设置基准以主干 LLVM，尽管 Emscripten 的更改比 PNaCl 的更改更容易重新设置基准。维护分叉的成本很高！