问我真的应该用make吗？

EN

这是我不久前对自己提出的一个问题。就我个人而言，我使用python脚本为AVR (链接)编译代码。我不是制造专家，但我确实有一些经验。尽管如此，我还是觉得这很令人沮丧，因为uC的需求毫无价值，除非你已经是专家了。

我并不鼓励任何人这么做，但是没有什么可以阻止您在Python中实现相同的依赖项检查(Perl、Ruby、Bash.)，甚至可能更强大。我相信这只是一个语言选择的问题，或者你觉得舒服的问题。make只是一种编程语言，对于初学者来说，它可能很难理解。

Make是一个值得尊敬的软件构建专家系统。它仍然被大量和广泛地使用，所以它是值得学习的。您可能很幸运，目前有一个几乎即时构建的项目，但是，在我的经验中，这是异常而不是规则。

鉴于依赖跟踪和动作推理是Make的目的，将其作为一个批处理系统使用是零增益，而且它也会干扰您学习如何使用该工具(Make)。

从你的帖子听起来，你似乎与使用Make的子目录发生了冲突。虽然它可能不能解决您当前的问题，本文：递归使被认为有害可能会帮助您解释情况，并让您深入了解Make本身的操作。

Make不会自动生成依赖项。您将在网络上找到许多资源，用于如何自动生成generate的依赖关系。我不确定OSX是使用GNU还是BSD (甚至BSD变体仍然存在)。如果是后者( BSD )，我相信您可以找到如何为BSD变体自动生成依赖项的菜谱。

我在这篇文章中推断的更多的存在主义问题是:当这个旧工具不能立即给我的项目带来好处的时候，学习它有价值吗？

在回答时，我想说:你的小项目是学习这个工具的绝佳机会。如果您面临的是增量编译确实节省了时间的项目，那么痛苦阈值肯定会高得多。

还有许多其他构建系统可以替代Make，例如：果酱、SCons、瑞克，或者充当元生成文件生成器：CMake，一些IDE。替换的数量之多表明，许多人认为不足(或者在某些情况下可能只是令人不快)。

然而，在可预见的未来，一点点的制造知识可能会对你有好处。这也可能是理解构建系统如何工作的第一个(或最明显的)步骤，以及与规则生成和依赖跟踪相关的问题。

祝你好运。

几乎任何非单一编译单元的非平凡C程序本身都有依赖关系，而且几乎所有的程序都依赖于系统库。

除非您打算每次编写一个执行干净构建的脚本，否则需要某种依赖管理工具来保持工作流程的正常运行。

make是规范的选择，并且非常适合作为工作，前提是您首先找到一种自动生成依赖规则的方法。

QT构建系统本身并不与Makefile集成，它通过更高级别的项目描述来创建它们。QTCreator是围绕这个过程提供GUI的众多工具之一。当您从QTCreator内部编译时，实际上调用的是结果Makefile。还可以使用qmake生成XCode和Visual工作区文件。

对于嵌入式项目来说，QT构建系统实际上是一个不错的选择，即使不使用QT，因为设置它来处理交叉编译相对容易。