提高 qmake 生成的 Makefile 性能答案

【问题标题】：Improving Makefile performance generated from qmake提高 qmake 生成的 Makefile 性能
【发布时间】：2011-07-12 16:57:52
【问题描述】：

我们的 Qt 4.5 项目有一个根 .pro 文件，其中包含一个 SUBDIRS qmake 变量。当对这个根 .pro 文件调用 qmake 时，它会为每个子目录生成一个调用“qmake && make”的 Makefile。

现在的问题是，对于 100 多个子文件夹，这需要很长时间才能检测到另一个明智的最新项目的单行更改。（大约需要 13 秒，很长。）在项目的根目录运行 make 首先将目录更改为所有子目录并运行什么都不做 make，直到找到它实际需要在其中工作的一个目录。（目前的一种解决方法是手动 cd 到您知道您在其中进行了代码更改的文件夹中，然后运行 make。对于我们的 eclipse 环境，这很笨拙。）

理想情况下，应该只调整根 .pro 文件，但我也会接受破解根 Makefile 的答案。

任何减少琐碎制作时间的建议将不胜感激。

【问题讨论】：

标签： c++ qt makefile

【解决方案1】：

这是recursive make considered harmful 理论的经典论据：您的问题是您有几十个单独的 Makefile 而不是一个大的。摆脱困境的唯一方法是重构 .pro 文件，以便只生成一个 Makefile。不过，我对 qmake 的了解还不够，无法告诉你如何做到这一点，抱歉。

【讨论】：

递归 make 的问题不是你有很多 Makefile，而是当你生成那么多 makefile 时你没有正确设置文件依赖关系。也就是说，由于您（qmake）害怕丢失一个依赖项，它会放置更多需要的依赖项。因此，make 需要的时间太长，因为它正在制作不必要的文件。
如果您正确编写递归 Makefile，它们的性能与您建议的方法相同。然而，这涉及到大量手动指示哪个文件具有哪些依赖项，这可能会变得很麻烦，但这是另一个问题。
@Shahbaz：Peter Miller 在链接的论文中确实指出（并且提出了一个强有力的案例，我认为）每个子 make 调用的依赖树的额外重新解析是一个重要因素时间运行。而且我认为 OP 在他的帖子中指出，多余的编译器运行似乎不是他的问题，而是“什么都不做”的调用。
有趣的是，您提到了递归 make 问题。在工作中，我按照那篇效果很好的论文构建了一个非递归的 make。我们也有 Qt 项目，一位聪明的 Qt 开发人员编写了一个从 qmake .pro 到 gnu make .mk 的转换器，仅使用 gnu make 函数，我们只是将 .pro 文件包含到构建系统中，它运行良好。所以是的，这是可能的。
@thiton，我读过这篇论文，在他的例子中，是的，有一个问题，但问题是因为在他的例子中，他以不正确的方式编写代码（图片这个：你首先制作可执行文件而不提供依赖项，然后制作对象，你显然失败了，这并不奇怪。这就是他所做的，以一种更不明显的方式）。而关于重建DAG，我真的不知道性能，我必须自己检查一下。不过我确实从论文中学到了一些东西，比如使用:= 而不是=（快速提问，我应该使用什么来代替+=？）