Eclipse CDT 没有在头文件更改时构建项目答案

【问题标题】：Eclipse CDT not building project on header file changeEclipse CDT 没有在头文件更改时构建项目
【发布时间】：2012-04-10 16:57:06
【问题描述】：

我有 Eclipse Platform 3.7.2 和 CDT 8.0.2。

当我想做“全部构建”时，来自其他工作区项目的标头不计为依赖项，并且不会重新构建任何内容。

我有一个 hello world 应用程序和一个静态库项目。静态库在项目属性 -> c/c++ 常规 -> 路径和符号 -> 引用选项卡 -> 选中“活动”中设置为参考。这是我唯一更改的设置。

顺便说一句，为什么 Eclipse 在项目属性下有一个额外的“项目引用”顶级项，这完全让我感到惊讶。

无论如何，我尝试了 External Builder（在项目创建时默认选择）和 INternal Builder，还结合了全局设置“Preferences -> c++ -> Build -> Build configuration only when there are Eclipse 资源变化......'

感谢您对此的任何想法。

更新：这是构建依赖项目 Proj2（Proj1 是 lib）时的控制台输出。 'make all' 被调用，但它只是重新链接，它不会重新编译 Main.cpp。有熟悉 eclipse 生成的 makefile 的人吗？再次感谢。

**** Build of configuration Debug for project Proj2 ****

make all 
Building target: Proj2
Invoking: Cross G++ Linker
g++ -L"/home/user/.eclipse-workspace/Proj1/Debug" -o "Proj2"  ./Main.o   -lProj1
Finished building target: Proj2


**** Build Finished ****

编辑：这已经有 1.5 年的历史了，想补充一下，已经为此提交了一个 Eclipse 错误： https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800

【问题讨论】：

我在更高版本的 eclipse/CDT 中看到了同样的情况。据我所知，构建正在生成 .d 头文件依赖项以包含在 makefile 中，但这些规则是不正确的。规则目标是 .d 文件本身而不是 .o... 这看起来是构建使用 -MT 选项错误地设置了 .d 目标的结果。不过，我看不出有什么办法可以改变这一点 - 你曾经解决过这个问题吗？
我无法解决。另请参阅我提交的 eclipse 错误，链接如下。
我现在有同样的问题。我更喜欢将导出的标头保存在根目录下的 /include 目录中，如果我更改了一个，如何让使用特定标头的源知道它已更改？
查看 Eclipse 错误。与此同时，人们发布了一些解决方法。

标签： eclipse reference header eclipse-cdt

【解决方案1】：

这个问题存在一个错误： https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800

还有一个有效且简洁的解决方法（原始请求者已经知道这一点）。所以我只是交叉链接到实际答案:) https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800#c11

Krzysztof Czaińsk 的所有作品

在您的项目 c 或 c++ 编译器设置中，在标志后添加 -MT ${OUTPUT_PREFIX}${OUTPUT}：

${COMMAND} ${FLAGS} -MT ${OUTPUT_PREFIX}${OUTPUT} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}

这将创建正确的 .d 文件

补充：解决方法有一个副作用。干净后make all 总是运行两次，然后才说什么都不做。仍然比更改后不编译要好;-)

【讨论】：

我知道，我去年报道过。 :) 从那以后已经被一些人证实了。我编辑了问题描述以使其更加明显。
我一定会尝试解决方法，应该非常有用。如果对我有用，会更新。
这对我有用。每次更改定义值时都必须清理非常令人沮丧。谢谢！

【解决方案2】：

最安全的做法是先“清理”主项目，然后重新构建。通常，当我知道主项目中的哪些文件使用修改后的头文件时，我只是“触摸”这些文件，然后重新构建。对我来说，“触摸”只是在一行上添加一个空格，通常是文件顶部的 #include 行之一。然后该文件重建并拾取修改后的标头。其他可能使用该头文件的文件不会被重建，所以这很危险。例如，如果您更改了方法调用的签名并以这种方式重建，则只有一个文件会正确调用新方法。从其他源文件调用可能会导致您的程序陷入陷阱。优势当然是重建速度。特别是在进行单元测试时，我确切地知道我将运行哪些测试，所以我只需触摸相关文件，重新构建运行。在某些时候为了安全起见，我总是做一个清洁/构建周期。通常我等到我需要更多的咖啡。

【讨论】：

如果您找到更好或更简单的方法，请告诉我。这是我发现让我的代码正确编译的唯一方法。我曾经尝试使用Project Properties->C/C++ General->Paths and Symbols，然后使用References 选项卡。我检查了我依赖的库。不幸的是，它把事情搞砸了，我花了一个小时才把它找回来，所以我已经避开了这个面板，但我认为这应该是解决库依赖关系的地方。
查看 Jan 的答案（上图）。它为我解决了问题。

【解决方案3】：

只是把它扔在那里，但您是否仍需要在客户端代码中包含静态库中的标头？在这种情况下，我认为您需要在项目属性的includes 选项卡中为您的客户添加标题。否则，我不确定您将如何实际访问客户端中的静态库实现。

至于references这两个选项卡，我相信C/C++ general中的一个可以针对不同的配置单独定义，而更通用的一个是针对任何配置的。

更新：
我建议使用您评论过的更通用的reference 选项卡。这应该确保您的客户端引用其他项目，无论客户端当前选择的配置或引用的项目是什么。

另一个更新：
我刚刚意识到您提到您更改的 only 设置是 references 设置。这是另一个远景，但我还要检查静态库的包含路径是否实际显示在项目设置的包含选项卡中（可能是）。我知道在编译时使用了正确的包含路径，但是在决定启动客户端项目的重新编译时，eclipse（可能）使用 this 选项卡来确定包含依赖项。也可能值得查看“源位置”选项卡并尝试将标题位置添加为源位置。

【讨论】：

设置项目引用将 -I（包含路径）添加到 g++ 编译器参数和 -lProjName 以进行链接。否则我无法编译。我可以进行干净构建并且它可以工作，当库标题更改时，什么不起作用是全部构建。我的客户端项目的编译器没有被调用。
嗯，好的。我想我读了你的问题，就好像它根本没有编译它。我能想到的唯一要添加的是检查静态库项目是否在其设置中具有适当的包含目录。不过，这似乎是您已经检查过的东西。祝你好运！
我不明白您所说的“库在其设置中包含其内容。在设置中的什么位置？我只是从客户端项目中包含它们并设置该参考。
暂缓我最后的建议，深夜写的:)。更多地考虑这个问题，我建议使用您评论的更通用的reference 选项卡。请参阅我的更新答案。
嗨！使用更通用的 References 选项卡也无济于事，当依赖项的标头更改时，依赖项目不会重新编译。它只是与库重新链接。查看更新的问题。