使用CMake和gcov时，.gcda文件未被创建

Question

我正在使用cmake与gcov。所有标志都已正确设置，并且.GCNO文件已正确创建。但是，当执行从源文件生成的可执行文件时，情况有点复杂。可执行文件在bash脚本中运行。

让我创建一个示例场景，以便您可以给出准确的答案。

我有一个名为MY_FILE.CC的文件，其可执行文件名称为EXECUTABLE_FILE。我使用了所有针对gcov设置的标志。我有一个名为THE_SCRIPT.SH的脚本，它将在“make test”下运行。此脚本运行EXECUTABLE_FILE文件。

因此，这里的想法是bash脚本（THE_SCRIPT.SH）反过来运行可执行文件（EXECUTABLE_FILE），而这些bash脚本的运行不会创建.GCDA文件。当我直接/手动运行可执行文件时，.GCDA文件被创建。我认为bash脚本在子shell中运行，父shell无法知道是否运行了源的可执行文件。请问有人能够确认这正是情况吗？如果不是，则确切的问题是什么？如果是，则如何解决此问题？

谢谢。

- Bilal Ahmad

---

我遇到了非常相似的问题。我正在尝试通过CMake POST_BUILD自定义命令运行单元测试并同时收集覆盖率。测试脚本可以正常运行，并成功运行测试可执行文件，但是没有生成.gcda文件。我相信这不是权限问题，因为测试脚本可以使用“touch”在与预期的.gcda文件相同的名称和位置创建文件而没有任何问题。可能是CMake用于启动测试二进制文件的环境中有某些gcov不兼容的内容...但我不确定具体是什么。 - William Payne

值得一提的是：在CMake之外运行测试脚本可以轻松生成.gcda文件；然而，在CMake内部却不行。 - William Payne

同时，在“make test”下运行时并不会产生.gcda文件...所以可能是由于make而非CMake导致的问题...？ - William Payne

你尝试直接执行“SCRIPT.SH”文件了吗？ - randomusername

在发布了上述问题后，我设法采取了一些措施来解决问题——现在一切都正常工作了，但我还是有点担心，因为我不明白为什么会出现我上面描述的症状。完全有可能是我做了一些愚蠢的事情，而我隔离问题的实验并不像我想象的那样“隔离”。 - William Payne

Answer 1

也许这个问题与您的问题有关。也许您可以提供更多关于标志、项目目录结构等方面的细节。

- aled

---

我之前看过那个问题，不幸的是它跟我的问题无关。我正在使用正确的标志进行编译（我可以生成.gcno和.gcda文件），它们确实被保存在了预期的目录中。我有一个带有相当复杂结构的外部构建树，但文件最终保存在了正确的位置，gcov和lcov也能够成功处理它们。正如我之前提到的-我认为上周测试时我做了一些愚蠢的事情；也许意外运行了一些清理代码，因为现在系统按照预期运行。 - William Payne

无论如何，我还是会给你赏金，并表示感谢，因为你花费了时间去追寻可能是一场徒劳的事情。 - William Payne