为什么（做）GCC（和其他工具）不遵循GNU命令选项约定准则？

Question

我正在对接受命令行选项的程序进行一些维护。有单个字母选项，以及长选项。目前，长选项只有一个前面的连字符。

许多工具都有长连接的双连字符。为了与外面的内容保持一致，我查看了一些GNU工具，并且从长形式看，有单连字符和双连字符的混合。例如，GCC编译器具有--help，--version与-std，-funroll-loops。

所以我搜索了一些关于此事的文档并找到了this GNU document。在那里，GNU对长选项的风格建议是从两个连字符开始。

现在，我想知道为什么GNU工具不遵循这些GNU建议？我认为这是向后兼容的问题，但还有更多吗？

在我编写的程序中，更改选项语法时，我通常会将旧表单保留为功能但未记录，或者至少提供弃用警告。 GCC（和其他）计划是否不可能这样做？

Answer 1

有很多理由不改变：

• 使用现有命令行选项的配置脚本和构建文件确实有数百万（可能更多？）。最近和非常老。
• 人们已经习惯了当前的格式，因此大多数程序员多年来只会习惯他们已经知道的习惯。
• 参数解析代码通常很复杂，改变它只是引入错误的另一个机会。
• 旧的向后兼容性单连字符长选项会与新的多个短选项冲突，因此难以向后兼容。
• 在此处插入更多内容。

改变的原因：

• 遵循许多应用程序已经没有遵循的惯例。

总之，惯例很好，理想情况下应该遵循新的东西，但通常只是为了整合而不值得改变。

Answer 2

Makefile和其他构建脚本通常编写（至少部分）编译器不可知，因此GNU C编译器（以及扩展名为GNU编译器集合gcc）必须与其他编译器保持兼容被称为。有些C编译器肯定早于GNU Program Argument Syntax Conventions。其他与开发相关的命令也是如此，例如ld，ar等，尤其是UNIX标准的那些部分。

＆＃39;传统＆＃39;某些命令中的语法甚至可能需要符合某些标准。 （C和C ++标准似乎只是指定了编程语言，但我可以想象UNIX标准还包含某些开发工具的命令行参数。）