4

使用 GCC 和 clang，我已经能够使用 SCons 的“TryCompile”功能来构建一个简单的配置检查，以确定当前配置的编译器是否支持给定的编译标志。基本上就是克隆 env，把有问题的 flag 添加到 CFLAGS、CCFLAGS 或 CXXFLAGS，酌情执行 TryCompile，如果 TryCompile 成功，则支持该 flag，我们可以将其添加到真正的 env 中。

  • 这与 gcc 完美配合，因为未知标志是错误并且编译器以非零状态退出。
  • 使用 clang，它也可以很好地工作：默认情况下，clang 将未知错误视为警告，但如果你传递它 -Werror 它会将未知标志转换为错误。所以我的 TryCompile 包装器总是通过 -Werror 以及要测试的标志，如果它知道我们正在使用 clang。

但是，这一切都被 Microsoft 工具链所破坏，因为据我所知，没有办法说服编译器将未知标志视为错误：它们始终是警告，即使您传递标志以产生警告错误也是如此。由于编译退出干净或不接受标志，TryCompile 总是成功。有关我为使 MSVC 以非零状态退出而进行的各种尝试的详细信息，请参阅此问题。

关于如何完成这项工作的任何想法？是否有另一个我忽略的 SCons 设施可以为我完成这项工作？我应该在 MS 平台上插入 TryCompile 并解析编译器输出而不是检查退出状态。我很高兴使用 TryCompile 通过 clang 和 gcc 进行配置时间标志检测，但如果我不能让 MSVC 合作，我将需要放弃这整个方法，我很讨厌这样做，因为到目前为止，它运行良好。

4

1 回答 1

1

让 Windows 再一次在游行中下雨 :) 显然，Windows 编译器总是返回成功，不管发生什么。

我能想到几个你可以尝试的选项。

首先，SCons 提供了多平台配置（Autoconf 功能），可以帮助您实现相同的结果。它不包括任何编译器选项，但至少包括以下内容：

  • 检查头文件是否存在
  • 检查函数的可用性
  • 检查库的可用性
  • 检查 typedef 的可用性
  • 添加您自己的自定义检查

另一种选择是使用 Microsoft 编译选项构建某种字典。每个编译器版本可能需要一本字典。这个特殊的选择可能需要很长时间来准备，而且可能不值得。

另一种选择是使用 Object() 或 Program() 构建器而不是 TryCompile() 构建器，并尝试捕获故障并做出相应的反应。我不确定 SCons 是否允许您将编译失败作为异常捕获并在失败时继续执行，但值得一试。

于 2013-03-09T11:45:10.867 回答