这是否是开发者文化忘记如何处理交叉编译工具链的体现？当我刚开始职业生涯时，人们普遍认为开发者可能在不同的系统和/或平台上操作源代码，而代码将在不同的系统上执行。我们的源代码控制、编辑、编译和执行被理解为发生在不同的计算空间中，中间可能有复制/暂存步骤。如果你假设可以在源代码文件存在以及编辑器/IDE运行的同一系统上执行构建的程序，那是一种非常天真的做法。这在我们曾经管理的构建规则中占了很大一部分。例如，配置步骤必须了解正在测量/表征的目标平台与执行构建工具的平台是不同的。要实际执行一个构建的对象可能需要远程文件复制和远程程序调用。
源讨论Git：引入Rust并宣布它将成为构建系统中的强制性语言原帖 413 条评论 · 导入时统计把你的经验，加入这段讨论。
实际上，Rust 工具链让交叉编译比我用过的任何其他编译型语言都要容易得多。只需设置 `--target` 标志，就可以针对大约 100 种不同的平台进行编译，而且它们几乎在任何主机平台上都能正常工作。 听起来真正的问题是，一些 Git 开发者对自己的开发机器有古老而僵化的具体要求。
完整原文我怀疑大多数开发者从未真正学习过。交叉编译几乎总是处于次要地位，我从不指望外部项目能正确工作。Linux 发行版已经放弃了，就连 Fedora 甚至坚持在像树莓派这样的平台上必须在真实的目标硬件上进行编译，这有点疯狂，结果基本上没人愿意花精力去让这变得可行。
完整原文> 这是否意味着开发者文化忘记了如何使用交叉编译工具链，这是自食其果？ 我不明白你的评论。完全忽略 Rust 的情况下，现代交叉编译的状态简直是一场灾难。 Linux 尤其糟糕，因为 glibc 是一个架构糟糕的垃圾堆，还停留在 80 年代。对于任何可能的 Linux 硬件环境，应该可以轻松地指定任何最低版本的 glibc。但 glibc 和 Linux 发行版甚至没有尝试实现这一点。Linux 工具链几乎让人无法避免使用默认系统库，这与交叉编译的正确做法正好相反。 Zig 努力让交叉编译成为可能。但几乎没有项目真正尝试支持交叉编译。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。