为什么 -o 是从 Microsoft 编译器和链接器中删除的候选对象？答案

【问题标题】：Why is -o a candidate for deletion from the Microsoft compiler and linker?为什么 -o 是从 Microsoft 编译器和链接器中删除的候选对象？
【发布时间】：2009-04-05 23:26:31
【问题描述】：

我遇到了以下问题，我想知道它会对我的 Cygwin/GNU 环境产生什么影响。我应该使用 -o 以外的其他名称来命名编译的输出吗？

是否有一些新标准被采用，其他编译器是否遵守它？

删除-o 的动机是什么？

DOS PROMPT> 输入compile.bat

cl.exe -D YY_MAIN=1 lex.yy.c libfl.obj -o foobar

DOS 提示> 编译

cl.exe -D YY_MAIN=1 lex.yy.c libfl.obj -o foobar
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.
lex.yy.c
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
/out:lex.yy.exe
/out:foobar.exe
lex.yy.obj
libfl.obj

cl：命令行警告 D9035：选项“o”已被弃用，将在未来版本中删除

正如下面的答案所问的那样，他们是否有意在 Windows 和 UNIX 之间制造更多裂痕？我希望不是。我希望我错过了所有编译器采用的一些新约定。

【问题讨论】：

标签： c visual-studio command-line

【解决方案1】：

我不一定会看到其背后的邪恶目的 - 它更有可能是一些与兼容性相关的事情（也许 -o 正在干扰某些构建系统或某些微软大客户或其他使用的其他系统。）

但是，当编译器供应商抛弃根深蒂固的做法和习得的反应时，这是烦人的。

但 Microsoft 编译器和 Unix 编译器之间的（语法和哲学）差异比简单的命令行开关更大。为此，您可以尝试摆脱简单的批处理构建脚本并转向 Makefile - 或者更好的是，使用实际的跨平台构建系统，例如 CMake 或 SCons（请注意，它们只是示例，我没有和他们中的任何一个结婚:)）。

【讨论】：

我将 -o 选项深埋在一个相当复杂的跨平台构建结构中。该示例将其归结为最简单的情况。
我明白了 - 那很糟糕......但是，可能有一个光明的一面（或者，更确切地说，一个稍微不那么黑暗的一面） - “将在未来的版本中删除”可能意味着 @VS2025 ，到那时你可能不再需要它了......
很晚，但我想-o 在引入优化的-O 时已被弃用，可能是在编译器选项不区分大小写的时候。它们现在区分大小写，因此这需要深入了解编译器历史，可能要追溯到 DOS 时代......
那么我们现在应该用什么来代替/o？

【解决方案2】：

是的。您应该使用/F 来设置编译器输出选项。

【讨论】：

从技术上讲，您可以直接找到答案，但我正在寻找它的动力。
这可能不是邪恶的，只是一些 PM 认为它需要发生。只有编译团队才能确定。

【解决方案3】：

Windows 上的命令行参数与 Unix 上的命令行参数不同。它们通常以 / 而不是 - 开头，cl.exe 的参数不一定与 Unix 上的 cc 匹配。

您要查找的选项似乎是/Fe

【讨论】：

但为什么要制造更多差异呢？
Windows 是与 Unix 不同的操作系统。 Windows 是从 DOS 发展而来的，后者起源于 CP/M，它受到 DEC 命令行环境系列的启发，该系列使用 / 作为命令行上的开关前缀。这也是用于行尾的 CRLF 的来源。
非常旧，但是：cl（以及所有 Microsoft 开发工具）也接受 - 作为选项标志。