Question

有没有办法检查cmake在失败的运行中做了什么？例如，我有一个程序取决于libbacktrace，我可以通过gcc foo.c -lbacktrace链接到该程序。但是当我写一个CMakeLists.txt之类的

时

cmake_minimum_required(VERSION 2.8)
find_library (BACKTRACE_LIBRARY backtrace)
message (BACKTRACE_LIBRARY=${BACKTRACE_LIBRARY})

并输入cmake <path>，打印出BACKTRACE_LIBRARY=BACKTRACE_LIBRARY-NOTFOUND。

如何确定问题所在？在放弃查找libbacktrace之前，cmake执行了哪些命令？它正在执行任何事情吗？在autoconf中，命令都记录在config.log中，但在这种情况下CMakeOutput.log为空。同样地，cmake --trace仅在一堆系统cmake文件之后回显CMakeLists.txt的内容，在这种情况下这是无用的。

请注意，我并没有找到一种方法来对find_library工作进行特定的调用 - 这只是一个例子。我的问题是：我有一个没有按预期工作的CMakeLists.txt;有哪些工具可以帮助我弄清楚它失败的地点和原因？

Answer 1

有no CMake debugger or similar¹。你能做的是：

读取CMake的输出，有时它已经提供了“缺少INCLUDE_MYLIB_DIR”等提示。删除CMakeCache.txt和/或删除构建目录，以确保不会丢失输出，因为结果已缓存。重复并检查缓存是否有影响。使用-Wdev会收到更多警告（针对CMake脚本的作者/开发人员，而不是用户）。更多有用的选项包括--warn-uninitialized，--warn-unused-vars和--check-system-vars，有关详细信息，请参阅documentation。
检查生成的文件，例如CMakeCache.txt和您生成的其他文件，如config.h或Doxygen的输入文件。具有您期望的值的变量是进一步研究的指标。
查看CMakeFiles子目录中的CMakeError.log和CMakeOuput.log。不幸的是，许多测试不会写入这些文件，但有些测试。例如，C编译器运行将编译器输出放在那里，这有助于发现非预期标志或错误（交叉）编译器的问题。
使用printf进行调试。这意味着当您大致知道问题的位置时，使用message输出中间变量。当您不知道如何评估分支或子表达式（具有AND或OR的表达式的一部分）时，这很有用。此外，您可以在内部放置“在mylib版本为> 3.2的分支”中的消息，以遵循工作流程。
降低复杂性。扔出你不知道的东西，直到你的问题消失。再次添加内容，直到问题再次出现。有时使用最小的示例更容易启动新模块来重现问题。令人惊讶的是，这通常有助于查明问题。
使用--debug-output（用于调试输出）--trace（完整跟踪）和--trace-expand（跟踪和扩展变量）进行调试。对于这些，在第5点取得进展是非常有帮助的，因为否则输出会淹没你。

¹好吧，有史蒂夫的CMake Daemon Tools。我自己并没有使用它们，但是它们声称提供了内省的可能性，这些内省似乎与调试器非常接近编辑现在，他们被称为CMake-server，并将成为CMake 3.7的一部分。您可以期待许多工具和IDE会选择它并改进我们开发CMake的方式。

Answer 2

除了上面提到的标志--trace（以及它的变量扩展同级--trace-expand），还有--debug-output。

来自文档：

--debug-output
  将cmake置于调试模式。

在cmake运行期间打印额外信息，如使用消息（send_error）调用的堆栈跟踪。

这可能会为您提供所需的信息。也许与--trace结合使用。

如何跟踪CMakeLists.txt

2 个答案: