在我看来,Make 只是一个简单的 shell 脚本,处理命令行参数稍微容易一些。
为什么标准的运行方式是 make 而不是./make. sh
一般的想法是,make支持(合理地)最小限度的重新构建——也就是说,告诉它程序的哪些部分依赖于其他部分。当您更新程序的某些部分时,它会重新构建依赖于该部分的部分。当你使用一个 shell 脚本来做这件事的时候,它将会是一个 很多更多的工作(显式地检查所有文件的最后修改日期,等等)使用一个 shell 脚本的唯一明显的替代方法就是每次都重新构建所有的东西。对于小型项目来说,这是一个非常合理的方法,但是对于大型项目来说,一个完整的重建可能需要一个小时或者更长的时间——使用 make,您可以在一两分钟内轻松地完成同样的事情..。
make
我可能还应该补充说,有相当多的替代品,使至少具有广泛类似的能力。特别是在大型项目中只重新构建少量文件的情况下,其中一些文件(例如 忍者)通常比 make 快得多。
Make 处理依赖关系: makefile 描述它们: 二进制文件依赖于对象文件,每个对象文件依赖于源文件和头文件... 当 make 运行时,将比较文件的日期以确定需要重新编译的内容。
可以直接调用一个目标,而不是构建 Makefile 中描述的所有内容。
而且 make 语法提供了替换,vpath
所有这些都可以用 shell 脚本编写,并且您已经拥有了它。
Make 确保在更改源文件时只重新编译所需的文件。
例如:
final : 1.o 2.o gcc -o final 1.o 2.o 1.o : 1.c 2.h gcc -c 1.c 2.o : 2.c 2.h gcc -c 2.c
如果我改变文件 2.h只 & 运行 make,它执行所有3个命令,在相反的顺序。
2.h
如果我改变文件 1.c只 & 运行 make,它只执行前2个命令在相反的顺序。
1.c
尝试用您自己的 shell 脚本实现这一点将涉及大量的 if/else检查。
if/else
有很多事情 make does 很难用 shell 脚本来完成..。
除了上述内容之外,Make 是一种声明式(- ish)并行编程语言。
假设您要转换4,000个图形文件和4个 CPU。尝试编写一个10行的 shell 脚本(我在这里已经很慷慨了) ,它可以在充分利用 CPU 的同时可靠地完成这项工作。
也许真正的问题是人们为什么要费心编写 shell 脚本。