请特别注意标签部分。
这个决定背后的理由是什么？合并是否会影响构建最新 binutils 和 GDB 的建议方法？ (事实上 ，当我 checkout binutils-2_25_1 并运行 make all && make install 时，我也得到了 gdb。)
最佳答案
我做了转换。我将它们加入存储库的原因部分是历史原因，部分是实际原因。
从历史上看，gdb 和 binutils 几乎一直在一起。当它们在 Cygnus 中维护时，它们位于单个源代码树(称为“devo”)中。后来，当 sourceware.org 成立时，他们共享了一个存储库(称为“src”)。您可能没有注意到这一点，因为存储库使用 CVS 模块让开发人员只检查树的一部分。
实际上，gdb 和 binutils 共享很多代码。他们共享他们的构建基础设施(configure 等)；它们共享支持库(libiberty 和 include)目录；他们共享 BFD 库；他们共享操作码库。对我来说，将它们放在一起更有意义，既可以避免不断地来回合并(这已经对使用 GCC 的某些组件完成了，这真的很痛苦)，也可以尽量减少对一个项目进行负面更改的问题影响对方。例如，至少在理论上，在 BFD 上进行常规开发的人应该构建 gdb 和 binutils。
共享存储库使用的顶级 configure 脚本允许开发人员使用 --disable-DIR 禁用任何特定目录。例如，如果您不想构建 gdb，请传递 --disable-gdb。
关于c++ - 为什么 GNU binutils 和 GDB 合并为一个包？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34037219/