在某个时候，我和一位同事从网上抓取了一个“示例”makefile，用于为 xmega 芯片构建我们的嵌入式代码。我们发现这种体验非常令人沮丧。我们俩都不是专家，充其量是新手。我们通过偶尔的调整/调整来获得。我们花费数小时阅读制造手册并投掷飞镖以尝试进行更严重的更改。
通常，当我们构建时，我们总是从一个干净的开始。因为自动依赖生成似乎不能可靠地工作，而且我们刚刚了解到这种方式更安全。由于它是一个嵌入式项目，在一个小型处理器上，编译实际上很顺利。眨眼间就完成了，这使我在这里提出了真正的问题：
如果我不使用 make 进行任何类型的依赖管理并利用增量构建，那么使用它而不是简单的 shell 脚本有什么真正意义吗？
我对编写 C 代码、python 和优秀的 bash 脚本更有信心。今天最新的挫折是试图将一些与 FreeRTOS 相关的源文件移动到子目录中。make 对我们来说唯一真正的优势是它在 OSX 上安装，并且 vi 和 QtCreator 和 XCode 具有与我们的 makefile 集成的一些能力（但我可以制作一个非常小的 makefile 在这里桥接）。
Make 是用于构建软件的古老专家系统。它仍然被大量使用，所以值得学习。您可能很幸运目前拥有一个几乎可以立即构建的项目，但是，根据我的经验，这是例外而不是规则。
鉴于依赖跟踪和动作推断是 Make 的目的，将其用作批处理系统是零收益，并且还会干扰您学习如何使用该工具 (Make)。
从您的帖子看来，您在使用 Make 与子目录时发生了冲突。虽然它可能无法解决您当前的问题，但本文：Recursive Make Considered Harmful可能有助于解释这种情况，并让您深入了解 Make 本身的操作。
Make 不会自动生成依赖项。您会在网上找到许多关于如何为 GNU Make 自动生成依赖项的资源。我不确定 OSX 是使用 GNU Make 还是 BSD Make（或者即使 BSD 变体仍然存在）。如果是后者（BSD），我相信您可以找到如何为 BSD 变体自动生成依赖项的方法。
我在这篇文章中推断出的更具存在性的问题是：当它不能为我的项目带来直接好处时，学习这个旧工具是否有价值？
作为回答，我会说：你的小项目是学习这个工具的绝佳机会。如果您面临增量编译真正节省时间的项目，那么痛苦阈值肯定会高得多。
还有许多其他构建系统可以替代 Make，例如：Jam、SCons、Rake，或者充当元生成文件生成器：CMake，一些 IDE。替换的绝对数量表明许多人认为 Make 不足（或者在某些情况下可能只是令人不快）。
但是，在可预见的未来，对 Make 有一点了解可能会让你受益匪浅。它也可能是了解构建系统如何工作以及与规则生成和依赖跟踪相关的问题的第一步（或最明显的一步）。
祝你好运。
几乎任何不是单个编译单元的重要 C 程序都会在其内部具有依赖关系，并且几乎所有都依赖于系统库。
除非您打算编写一个每次都执行干净构建的脚本，否则需要某种依赖管理工具来保持您的工作流程健全。
make是规范的选择，如果您首先找到一种自动生成依赖规则的方法，则非常适合工作。
QT 构建系统本身并没有与 Makefile 集成，它是根据项目的更高级别描述创建它们。 QTCreator是围绕此过程提供 GUI 的众多工具之一。当您从内部编译时，QTCreator它实际上Makefile是调用的结果。您还可以使用qmake生成 XCode 和 Visual Studio 工作区文件。
对于嵌入式项目，QT 构建系统实际上是一个相当不错的选择，即使不使用 QT，因为它相对容易设置来处理交叉编译。
这是我不久前给自己提出的一个问题。我个人使用 python 脚本来编译我的 AVR 代码（链接）。我不是制造专家，但我确实有一些经验。我仍然觉得这很令人沮丧，而且对于 uC 的需求毫无价值，除非你已经是专家了。
并不是说我会鼓励任何人这样做，但是没有什么可以阻止您在 Python（Perl、Ruby、Bash...）中实现相同的依赖检查，甚至可能更强大。我相信这只是语言选择或您觉得舒服的问题。make 只是一种编程语言，对于初学者来说可能看起来很晦涩。
我个人不会直接使用 make，几乎不管你的系统有多大（这意味着在极少数情况下，我可以在极小的系统上使用它）。我会使用为您生成生成文件的工具。当然，您会丢失安装在股票操作系统上的部分，但会摆脱很多头痛。
我个人建议你看看 cmake 和 autotools。我个人更喜欢 cmake，发现它很棒，而 autotools 消除了一些令人头疼的问题，但增加了一些新问题。我发现其中任何一个都比makefile更好。
Cmake 还有一个优点是它更跨平台，可以创建makefile、visual studio 文件、code::block 文件等等。它还支持完整的源外构建，这意味着您可以创建一个 _build 文件夹，然后从那里构建。然后将所有生成的文件放入 _build 文件夹，而不是污染源代码树。
编辑：回答你的问题：我会学习基本的制作文件，以了解它的作用。但后来我会切换。所以我会学习make，但不会使用它。
除非您使用的是 IDE，否则 make 确实是此类事情的事实上的工具，除非您想在这条路上走得更远并使用 automake 或类似工具。我认为这对你的情况来说太过分了。
自动依赖生成有点棘手，但您通常可以在网络上找到有效的配方。我不确定你有什么具体问题，但也许这值得一个单独的问题。
bash 脚本可能足以满足您的需求；如果这是真的，那就去吧。鉴于您更熟悉 Python，您可能还想查看类似SCons的内容。
我已经完成了相当多的 Makefile 工作，但我正在转向 Rake。我发现 Ruby 的强大功能比 make 更能满足我的需求。
如果您每次都进行完整构建，那么每次使用 make 运行完全相同的命令序列不会给您带来真正的优势。但是，make 是一个非常强大的系统，而避开它是错误的。Make 加起来比你希望用自定义的“python 构建脚本”拼凑起来的要多得多。
即使这个项目足够小，可以从头开始快速构建，你很快就会解决更大的问题。使用简单的用例比使用复杂的用例更容易学习 Make。您说“自动依赖生成似乎无法可靠地工作”：如果您正确定义依赖关系，则 make非常可靠。所以你的设置一定有错误（下面有更多内容）。
即使您总是从头开始构建，Make 也很有用：您可以使用 Makefile 作为所有与构建相关的命令的容器，而不是手工制作一堆小的构建脚本，所有命令都由相同的符号变量控制：例如，如果你有一个变量ALLSOURCE，你可以将它与创建 zipfile、ctags 索引等的伪目标一起使用（也make clean可以这样工作）。如果您为所有内容编写单独的批处理脚本，那么随着项目的发展，您将争先恐后地更新它们——而且它们会无缘无故地弄乱您的目录。
但你说，你不能让依赖项可靠地工作。我怀疑从别人的示例脚本开始是一个错误：它可能做了太多你不需要的事情，而且不完全理解。从一个干净的 Makefile 开始，为您生成的二进制文件添加目标，然后编写您自己的依赖项。把事情简单化; 如果您的项目非常容易构建，以至于您甚至考虑编写自己的脚本，那么为它编写一个 makefile 应该很容易。如果您遇到困难，请在此处提出具体问题。