crylearner的专栏

转自：http://blog.sina.com.cn/s/blog_7195909a0100zi7i.html 关键点： 1. #include  不会搜索当前目录                 2. 使用 -I 参数指定的头文件路径仅次于 搜索当前路径。                3.  gcc -E -v  可以输出头文件路径搜索过程 C++编译

长话短说，没有envsetup.sh, 当你需要单独编译一个模块，或者做点其他工作时，你总是会感到为什么命令行总是那么麻烦！有了envsetup.sh, 对命令行人生有新的感悟，原来我也可以做一个简单的“菜鸟”。 这个envsetup.sh是从android的代码中考过来的，做了很大的简化。google他奶奶的太细心和繁琐了，这里用不着 可用通过usage命令查询， 目前仅支持 genmk

经过这么长的时间，我们的通用makefile已基本构建完成，下面使用一个具体的Examle，作为如何使用的说明。 我们这个例子为之前写的hello world编写单元测试。单元测试的工具使用gtest，比较简单嘛。 从官网上下载gtest源码包，解压后，里面有个fused-src目录，在里面就是gtest文件夹，包括1个头文件gtest.h, 两个源文件gtest_all.cc, gt

” 　停在这里不敢走下去，   　　让悲伤无法上演 　下一页你亲手写上的离别，　由不得我拒绝 　这条路我们走得太匆忙，　　拥抱着并不真实的欲望， 　　来不及等不及回头欣赏 “ （摘自《步步惊心 》片尾曲 《三寸天堂》） 走到这里，实际上我们的makefile框架已经是搭得差不多了。这一路小跑过来，感觉一切都很美好，实际上我想，我们只是太匆忙，来不及细细回想。 如果

上一次我们试图引入多模块，结果失败了，今天我们来帮助失败实现做母亲的愿望。在正式开始之前，先做一个孕前检查 我们上一次的失败原因有两个 1. 编译目标重定义。 2. 一些变量定义被覆盖。 这些实际上是递归形式的多模块makefile必然要遇到的两个问题。 对症下药的药方就是makefile中的“多规则目标”（具体参看makefile必知必会），简单而言就是三句话： makefile允许目标的依赖关系通过多个规则定义，但是实现该目标的命令只能在一个规则中定义，实现时会自动合并该目标所有的依赖关系。 下面来

通用makefile系列收视率比较惨淡，工程本身也进入尾期，这里直接大跃进喽 上类图 类图画得不好，所以下面文字简单解释 1. 整个通用makefile分为若干大块，也就是上面用包表示的部分，主要是产品Product，编译平台Platform，操作系统System，模块Module，编译目标Target，以及Build和Path这两块。    产品Product，编译平台P

今天我们尝试引入多模块，这次很有必要的。模块化开发嘛 既然是多模块，首先应该引入模块的概念，module.mk. 直接将main.mk中的内容移动到module.mk即可 编译时就会发现一堆错误，主要是有这么几个问题 1. 提示编译目标clean重定义。 这个原因是makefile允许目标的依赖关系多次定义，但是实现目标的命令只能在一个规则处定义。当我们include多个module.mk时，显然clean目标被重复定义了 2. 有些变量的值有些莫名其妙了，特别是OBJS， DEPS，等，

要解决这个头文件依赖关系的自动推导问题，呵呵，GNU中直接有尚方宝剑MMD，MF， MT。 走到这里，感觉人生已经无欲无求了，通用makefile真的已经通用了。However，我又是看得太远，看这段makefile，我想到两个问题 1. 上面的生成obj文件和.exe文件的代码是很形式化的，如果可以应该同product一样，单独归类到某个文件夹中，防止在修改makefile时不小心改了这些代码 2. 如果我是多模块编译，怎么办呢？ 路漫漫其修远兮，吾将上下而求索...

类似于产品信息，对平台相关的信息，我们也提供了一个定制化途径，通过加载PLATFORMS_SPECS指定的mk文件，定制平台信息。 对System，我们没有提供额外的客制化手段，这是因为操作系统是固定的，不会在编译过程中发生改变，一般直接在system.mk中配置即可。

这个系列会一步步的从最简单的makefile逐步导向一个较为通用的makefile（没有“复杂”两字）。您可以在这个过程中，学到makefile的基本语法，也可以学到makefile的常见技巧，同时我相信，您也会对如何做代码修改有所领悟

上一次我们完成了圈地运动，顺利拍下一块叫做build的地块。今天，我们就要在上面立个牌坊 一般情况下，我们总会在makefile中加入一些产品信息。比如产品名称，版本号，以及产品的特性开关（宏），等等。 今天的工作就是加入产品信息，并同时与makefile解耦。

makefile必知必会（II） 定义变量 makefile的变量定义有三种方式 1.        立即赋值 a:=b 2.        延迟赋值 a=b 3.        条件赋值 a?=b 4.        附加赋值 a+=b 它们之间的区别是， 第一种方式，会立即计算b的值，并赋值给a； 第二种方式，相当于C++和java的引用。如果后面b的值改变了，那

Makefile 必知必会 Makefile的根本任务是根据规则生成目标文件。 规则 一条规则包含三个：目标文件，目标文件依赖的文件，更新（或生成）目标文件的命令。 规则：                 目标文件>:依赖文件>          更新目标的命令>    PS：更新目标命令必须以tab开头，这个有点恶心。 Example    

转自：http://blog.youkuaiyun.com/zdl1016/article/details/9015447 潜规则1: 当一个符号在多个目标文件(.o)里同时出现时, LD报错. 提示符号多重定义. 当一个符号在多个静态库(.a)里同时出现时, LD不报错, 以第一个遇到的为准. 并且不会有任何warning提示 !!! 这个潜规则可能导致很多意想不到的问

相关的生成obj的编译规则，自动导出头文件依赖关系的命令，以及生成可执行文件的规则，都集中到executable.mk。这时，我猜你肯定会立马相当，是不是还要有一个static-library.mk, shared-library.mk?binggo，这是必须的。（这里简化起见，我只讨论static-library.mk）。当开始专注于编写static-library.mk时，会发现obj的生成规则可以复用，所以我们又将obj的生成规则集中到object.mk TARGET:=hello.exe #