全部学习汇总：
https://github.com/GreyZhang/g_makefile
最近因为工作需求，得重新面对Makefile。我之前也通过各种脚本替代国Makefile的功能，比较傻瓜化但是其实对付一般的小工程还是可以的。那么为什么又回到了Makefile呢？因为我觉得或许这个也是一种方法论的体现，加上这也算是古老技术的传承，如果精通了处理问题或许会更加优雅。
我有过几次直接读make手册最终失败告终的经历，这一次我放弃了啃读枯燥的手册，把方式转到了跟随网络教程上。每天花点时间了解一点点，也是想看到量变到质变的效果。前面几天其实还算是顺利，今天运行一个基本的历程的时候失败了。相应的makefile如下：
cc := gcc
objects = foo.o bar.o all.o
all: $(objects)
# These files compile via implicit rules
# Syntax - targets ...: target-pattern: prereq-patterns ...
# In the case of the first target, foo.o, the target-pattern matches foo.o and sets the "stem" to be "foo".
# It then replaces the '%' in prereq-patterns with that stem
$(objects): %.o: %.c
all.c:
echo "int main() { return 0; }" > all.c
%.c:
touch $@
clean:
rm -f *.c *.o all
最初的版本中gcc都没有赋值，我还是我修改过的。在windows系统下，使用gmake进行make的时候出现了一个错误。具体如下：
尝试对比，没有跟例程代码发现任何差异。我好奇，去WSL下做了一下测试，没想到通过了。效果如下：
那么，到底是为什么呢？难道是因为不同的操作系统之间会有差异？或者是make工具之间的差异？针对这方面，我做了一系列的尝试排查。
首先，查看make工具的版本：
这是WSL上的工具版本信息，接下来看Widnows下的gmake版本信息。
巧合了！通过上面的信息查看，其实这两个就是一个工具的同一版本。那么，为什么会有差异呢？我试了我手头已经有的几个不同的make、gmake以及dmake，最终都没有成功。最后，还是回到了make的文档。首先搜索了windows关键词，没有看到什么特殊点。后来，逐个章节浏览，运气很好，一下子看到了一个可能的差异点。
上面是文档的
原文
，从这里可以看得出来其实这个CC应该是大写的。但是我找到的例子里面是小写的，做一个简单的修改测试。
Windows系统下顺利通过。make手册中的描述看信息应该是linux为主，不过以防万一一同测试了一下，功能依然是正常的。不过，两个环境下编译速度有着很大的差异，linux下的效率明显是要高一些的。
或许，这算不上什么大的知识点，只是hack、学习过程中的小插曲。但是正是解决一个个类似小问题的过程，让我们的hack生活充满了快乐！
