如何跟踪 CMakeLists.txt [英] How to Trace CMakeLists.txt

问题描述

有没有办法检查 cmake 在失败的运行中做了什么?例如，我有一个依赖于 libbacktrace 的程序，我可以通过 gcc foo.c -lbacktrace 链接到它.但是当我写一个 CMakeLists.txt 像

Is there a way to examine what cmake is doing in a failing run? For example, I have a program depending on libbacktrace, which I can link to by gcc foo.c -lbacktrace. But when I write a CMakeLists.txt like

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

并输入cmake ，它会打印出BACKTRACE_LIBRARY=BACKTRACE_LIBRARY-NOTFOUND.

我该如何找出问题所在?在放弃查找 libbacktrace 之前，cmake 正在执行哪些命令?它是否正在执行任何操作?在autoconf中，命令都记录在config.log中，但是CMakeOutput.log在这种情况下是空白的.同样的，cmake --trace只是在一堆系统cmake文件后回显CMakeLists.txt的内容，在这种情况下是没有用的.

How do I go about figuring out where the problem is? What commands is cmake executing before giving up on finding libbacktrace? Is it executing anything at all? In autoconf, the commands are all recorded in config.log, but CMakeOutput.log in this case is blank. Likewise, cmake --trace only echoes the contents of CMakeLists.txt after a bunch of system cmake files, which is useless in this case.

请注意，我不是在寻找一种方法来使 find_library 的这种特定调用起作用 - 这只是一个示例.我的问题是:我有一个没有按预期工作的 CMakeLists.txt；有哪些工具可以帮助我找出失败的原因和原因?

Please note that I'm not looking for a way to make this particular invocation of find_library work - that's just an example. My question is: I have a CMakeLists.txt that isn't working as expected; what tools exist to help me figure out where and why it's failing?

推荐答案

没有 CMake 调试器或类似工具¹.你可以做的是:

1. 阅读 CMake 的输出，有时它已经给出了缺少 INCLUDE_MYLIB_DIR"之类的提示).删除您的 CMakeCache.txt 和/或删除构建目录，以确保您不会因为结果已缓存而错过输出.重复并检查缓存是否有影响.使用 -Wdev 会收到更多警告(这些警告是针对 CMake 脚本的作者/开发者，而不是针对用户的).更有用的选项是 --warn-uninitialized、--warn-unused-vars 和 --check-system-vars，请参阅 文档 了解更多详情.

1. Read the output of CMake, sometimes it already gives hints like "missing INCLUDE_MYLIB_DIR"). Delete you CMakeCache.txt and/or remove the build directory, to be sure you don't miss output because the result was cached. Repeat and check whether caching had an influence. You get more warnings (those meant for the author/developer of the CMake script, not for the user) with -Wdev. More helpful options are --warn-uninitialized, --warn-unused-vars and --check-system-vars, see the documentation for more details.

检查生成的文件，例如 CMakeCache.txt 和您生成的其他文件，例如 config.h 或 Doxygen 的输入文件.您期望值不同的变量是进一步研究的指标.

Check the generated files like the CMakeCache.txt and additional files you generate like a config.h or input files for Doxygen. Variables with values you expect different, are indicators for further research.

查看 CMakeFiles 子目录中的 CMakeError.log 和 CMakeOuput.log.不幸的是，许多测试不会写入这些文件，但有些会.例如，C 编译器运行将编译器输出放在那里，这有助于发现意外标志或错误(交叉)编译器的问题.

Have a look into CMakeError.log and CMakeOuput.log in the CMakeFiles sub-directory. Unfortunately, many test do not write into these files, but some do. For example C compiler runs put the compiler output there, which helps to find the problem with unintended flags or wrong (cross-)compilers.

使用 printf 进行调试.这意味着当您大致知道问题所在时，用message 输出中间变量.当您不知道如何评估分支或子表达式(带有 AND 或 OR 的表达式的一部分)时，这很有帮助.此外，您可以将诸如in branch where mylib version is > 3.2"之类的消息放入其中以遵循工作流程.

Debug with printf. This means when you roughly know where you problem is located, output intermediate variables with message. That is helpful, when you don't know how a branch or a sub-expression (a part of a expression with AND or OR) is evaluated. Further you can put messages like "in branch where mylib version is > 3.2" inside to follow the workflow.

降低复杂性.扔掉你不知道的一切，直到你的问题消失.再次添加内容，直到问题再次出现.有时，使用最少的示例启动一个新模块来重现问题会更容易.令人惊讶的是，这通常有助于查明问题.

Reduce complexity. Throw everything out you don't know, until your problem vanishes. Add the stuff again until the problem reappears. Sometimes it is easier to start a new module to reproduce the problem with a minimal example. Surprisingly, this often helps to pinpoint the problem.

使用 --debug-output 调试(用于调试输出)--trace(完整跟踪)和 --trace-expand(跟踪和扩展变量).对于这些，在第 5 点取得进展非常有帮助，否则输出会淹没你.

Debug with --debug-output (for debug output) --trace (complete trace) and --trace-expand (trace and expanded variables). For these it is extremely helpful to make progress with point 5., because otherwise the output will flood you.

¹好吧，有 steveire 的 CMake 守护程序工具.我自己没有使用过它们，但它们声称提供了似乎非常接近调试器的自省可能性.
它们现在被称为 CMake-server 并将成为 CMake 3.7 的一部分.您可以期待许多工具和 IDE 会采用这一点并改进我们开发 CMake 的方式.

¹Well, there are the steveire's CMake Daemon Tools. I haven't used them myself, but they claim to offer possibilities for introspection that seem to be pretty close to a debugger.
They are now called CMake-server and are going to be part of CMake 3.7. You can expect that many tools and IDEs will pick this up and improve the way we develop CMake.

这篇关于如何跟踪 CMakeLists.txt的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！