澄清
当我提到交叉编译时，我的意思是从一种语言到另一种语言（想想 GWT），而不是从主机平台到目标平台。
背景
我正在开发一种交叉编译为 Java 的阿拉伯语编程语言，这为我节省了特定于平台的麻烦。现在我不得不搁置它并出于各种原因转向交叉编译到C。
我想开发一个单独的库，在编译时将其替换为运行它的系统的等效库。
例如，如果程序员用阿拉伯语编程语言编写一个GUI绘图函数并编译，在Windows下编译会交叉编译成win32代码，在Gnome下编译GTK+，在KDE下编译Qt等。图书馆也是如此。
问题
是否值得通过所有这些麻烦来结束编译的可执行文件，或者我最好使用虚拟机方法？选择其中一个的优点和缺点（从语言开发人员的角度而不是使用该语言的程序员的角度）？还有其他我需要考虑的因素吗？
任何进一步阅读的参考链接将不胜感激:)
您应该交叉编译为最能支持您的语言背后的假设和想法的语言。如果您的语言是垃圾收集的，所有函数调用都是方法调用，并且不允许您将地址用作数据，那么 Java 就是要编译的语言。
有些编译器可以将 Java 代码编译为本机代码。所以如果你想让你的程序在本地运行，你可以使用它们。
当您准备好为您的语言制作自己的完整编译器时，您可以将自己与 Java 或您选择的任何东西分开。
这种基本方法已被多种语言使用。通常目标语言是 C，因为你可以在 C 中做其他任何语言都做不到的低级东西，它有成熟的优化编译器，并且在本地运行非常快。C 的符号、库和调用约定的工作方式也很容易理解，并且在任何给定平台上都得到了多种语言的严格定义和支持。这使得新语言可以立即访问为 C 编写的大量库。
C++ 是这样开始的（最初的编译器叫做 cfront），我相信 OCaml 也是这样开始的。我认为，如果您稍微挖掘一下，您会发现许多其他语言都是如此。
但是如果你不需要 Cs 的低级特性，那么很多这些论点也适用于 Java。许多较新的语言（例如 Scala）以这种方式使用 JVM。
我喜欢@Omnifarious 的回答，但我要强调的是，您必须考虑要做出哪些权衡。如果您想要高性能，您可以选择交叉编译为 C 或 C++，如果您想要库的可用性，C 或 C++ 也是不错的选择。如果您想要语言互操作性，您可能会使用 LLVM 汇编器、JVM 或 .NET 汇编器。
所以现在，你的实际问题是：你应该让后端可插拔吗？我必须警告你，这真的 很难做到。让我们看看一些真正做到这一点的产品：示例当然是 gcc。它旨在不仅支持多种输入语言，还可以为多种目标 CPU 生成代码：您可以将其视为生成各种汇编语言的交叉编译器。
使后端可插入的秘诀是一种合适的中间语言，它足够简单，可以将您的输入语言翻译成，并且足够简单，可以翻译成各种后端语言，但又足够强大，可以对输入进行编码。
基本上问题是：如果你让你的 IL 过于抽象，它会锁定太多你的假设不能轻易改变。如果你把它做得太具体，就很难翻译成多个后端。
因此，我认为当且仅当您至少有三种潜在的后端目标语言可以作为用例来指导您的 IL 设计时，您才应该考虑这样做。