构建是软件开发过程中最常见的活动之一，也是很容易被忽视的环节。规范以及高效的构建对软件开发过程而言是大有裨益的。C语言并非一门年轻的语言，其历史已甚为悠久了(相对于还年轻的IT领域^_^)。从C语言诞生以来，市面上存在的C语言应用何止千千万万。这些C应用的源码组织形式种类万千，从最简单的单个源文件，到复杂的诸如Apache httpd server这样庞大的Project。不过无论这些C应用的源码组织形态如何，构建都是这些应用开发过程中必不可少的一步。

伴随着C语言的普及，C语言应用的构建工具也逐渐发展起来，随着Project构建复杂性的增加，大致可分为四个阶段(个人观点)：
* 命令行构建
对于简单应用来说，其源文件数量一般较少，且可能都放在一个同目录下，构建这样的工程的最简单的方法就是直接在命令行上输入编译命令(诸如gcc -o foo foo.c bar.c)。这种方式在C诞生早期的简单应用或对于刚刚C入门朋友来说是最常见的。

* make工具
随着Project复杂程度的增加，使用命令行编译构建的难度日益加大，大家开始使用make工具。make工具的实质是帮助项目管理依赖关系。C应用构建的最终目标一般都是一个可执行文件，该文件一般是由所有源文件的目标文件以及依赖的第三方库链接后生成的，也就是说该文件依赖项目源文件的目标文件以及第三方库。我们可以将这种依赖关系用make工具指定的专用语法描述出来，形成Makefile文件。后续我们如果要构建该Project，只需敲入make即可。make工具会自动分析Makefile中的依赖关系，并执行依赖关系对应的命令，并最终完成构建。

* autotools
虽然make工具很好地解决了复杂Project的构建问题，但make本身的学习曲线也是很陡峭的，也就是说要为一个复杂的C应用编写Makefile脚本并非易事，特别是复杂Project中那更为复杂的依赖关系，可以让任一一个程序员望而却步。大家都看到了这一点，因此就有了autotools工具集的诞生。autotools工具集由autoconf、autoheader、automake和libtool等工具组成，其主要目标就是简化项目Makefile的编写。使用autotools，我们可以为C应用的Project自动生成Makefile，这显然是一个很大的进步，对于复杂的Project尤甚。

* 新兴的通用构建工具
虽然autotools的出现解决了一些C应用构建难的问题，但autotools自身使用起来也是略显复杂的。特别是它由若干工具组成，并需要这些工具一起配合才能完成一个Project的Makefile的编写和生成，学习这些工具本身也要耗费很多时间。随着一些脚本语言的流行，一些新兴的通用构建工具逐渐出现在大家的视线中，诸如Scons、rake等。这些新工具吸取了make等门槛较高、不易用的教训，利用脚本语言特有的性质打造出了更加简单易用的构建脚本，现在很多C应用都开始使用这些工具简化构建脚本编写了。

究竟是使用哪种构建工具，这还是取决于项目所处的"环境"，包括项目的复杂性，人员的平均技能水准等等。但有了构建工具还不足矣，我们再来看看关于C语言应用构建还有哪些应该关注的地方。

一、规范化项目源码组织
项目的源码组织是应该先于构建脚本实现的，因此良好的项目源码组织也有助于构建脚本的编写，同时也有利于组织内部的标准化和复用。但C应用的源码组织的确没有统一的标准，也没有最好可言，也许只有适不适合。下面就是我们所使用的一个典型的C应用(非公共库)源码组织示例：

Foo_proj/
    – Makefile
    – sub_proj1/
        – Make.rules(由buildc生成)
        – Makefile
        – include/
        – module1/
            – xx.c
            – Makefile
            – tests/
                – xx_test.c
                – Makefile
        – module2/
            … …
    – sub_proj2
        – Make.rules(由buildc生成)
        – Makefile
        – include/
        – module1/
            – xx.c
            – Makefile
            – tests/
                – xx_test.c
                – Makefile
 … …

针对这个示例有几个注意事项要说明一下：
a)
以前在很多Project中，都会包含一个顶层的(toplevel)Make.rules，这样的设计考虑无非是希望项目下的其他sub_proj可以复用该Make.rules，这看起来似乎方便了。但实际这样做是在各个子项目间建立了一层构建耦合关系：很多子项目都有个性化的构建需求，这样一来可能会频繁对该顶层Make.rules进行修改；或是当无法修改顶层Make.rules时子项目还是会在自己下面增加一个子Make.rules以满足构建的个性化需求。我们莫不如去掉顶层Make.rules，而在各个子项目中添加自己的Make.rules。特别是在有了buildc工具以后，每个子项目下的Make.rules都是自动生成的，这样不但不会增加太多的额外工作量，还从根本上去除了子项目间的一种耦合，完全可满足sub_proj的个性化的构建需求。

b) 顶层的Makefile依旧保留，一般作为一键构建整个项目时之用。顶层的Makefile实际来看就是将各个sub_proj串接起来，再说白些，就是遍历的调用各个sub_proj下的Makefile。

c) 针对每个module的单元测试代码与被测试的module代码存放在一起(比如放在module下面的tests目录下)，这样使得被测对象与测试代码物理上接近，易于源码的测试，同时逻辑上看也很紧凑。

二、构建执行的简单和高效
构建是一个频繁的日常开发活动，简单和高效是IT开发者对"构建"活动的两个基本要求。所谓"简单"就是尽量不让或少让我动手，懒惰的程序员们最多只是希望敲入一个命令就可以完成项目的所有构建，这就是我们所说的"一键化"。一键化从另一个角度来说也是一种"高效"，但"高效"更重要的含义则是指尽量缩短构建的时间。要想做到这点，一是需要一个清晰明了的构建脚本实现，把项目内部的各种依赖关系打理清楚，只作必要依赖，减少不必要的重复构建；第二则是选择一款高性能的构建工具，目前来看make本身的性能还是很棒的，一般来说还是强于scons这样以动态脚本语言实现的工具的，特别是再加上并行编译和分布式编译后，构建时间将大大缩短。

三、第三方依赖包的管理
在开源软件大行其道的今天，很多商业项目都或多或少的用到一些开源包，即使没有用到开源包，组织内部也可能存在项目间相互依赖的情况，比如：业务部门的应用很可能依赖基础研发部门提供的通用库，这样就出现了一个第三方依赖的管理的问题，这也是我们在进行构建设计过程中所不可忽视的一个重要方面。

关于第三方依赖包的管理，至少我是见识过如下几种方式：

* 将第三方依赖包的源码导入到你的项目，伴随项目一并构建
这样做的好处之一就是完整：大家在构建项目时无需东找西寻，依赖的代码就在项目库中。好处之二是便于一键构建，依赖包的源码就在项目中，可以任你"宰割"；第三则是便于在不同平台上移植，因为直接存储了源码，在每个平台都是依据所在的平台构建对应的版本。

不足之处：这样做会导致项目代码库庞大，构建时间漫长；另外也不便于第三方依赖包的更新升级。一旦第三方依赖包有bugfix或新feature，你可能需要手动的同步代码。一旦依赖的第三方包有很多的话，这可是一笔不小的工作量；最后每个项目都单独存储一份第三方依赖包会导致大量重复，重复可并不是一个好味道。

* 将第三方依赖包构建后的二进制文件放入项目代码库
这样做的好处在于提高了构建效率，节省了第三方依赖库自身的构建时间。但这样做的不足之处依然很多，直接存储源码方式的大多数不足都被该方式继承了下来，除此之外，这种方式还会导致在不同平台上构建难度的增加(不同平台上的包的二进制文件是不同的)。

* 对第三方依赖包进行集中单独管理
将各个项目所使用的第三方依赖库做统一集中管理，而不是放在每个项目中，并且只存储构建后的二进制文件而非源码。组织形式示例见下面：

3rds/
      – libevent/
           – 2.0.10/
              – README
              – source_code_package
              – sparc_32_solaris/
    - include/
    - lib/
              – sparc_64_solaris/
              – x86_64_solaris/
              – x86_64_linux/
           … …
      – netsnmp/
      … …

这种"分门别类"的第三方依赖包集中管理方式既有利于加速构建过程(直接用二进制，省下源码编译)，同时也便于依赖包的统一升级和管理(专人负责，通过版本号区分)。这种第三方依赖包的管理方式也是使用buildc构建辅助工具的前提。这种方式也是有缺点的，那就是需要有专人负责对该公共库进行管理，包括新版二进制包的制作与上传。

至于在具体项目中究竟采用哪种方式还需要根据project的具体情况作出权衡，如果你依赖的第三方包较小且很少，那方式一很适合，redis就是这么做的；如果你不要支持多平台，那么第二种方式也可行；对于组织而言，似乎第三种方式是规范、统一和一致的，这也是我推荐的方式。

四、适于与第三方工具集成
持续集成是公认的优秀实践，市面上有很多优秀的ci工具。持续集成的第一步就是构建，因此一个好的工程构建是应该能与ci工具很好结合在一起的，也就是说要充分考虑构建脚本与ci工具的结合。

一般来说持续集成工具判断成败与否的根据就是你委托ci工具执行的脚本的返回值。对于C应用构建过程来说，一般是make的返回值。0即成功，其他均为失败。对于单元测试用例的执行过程而言，也同样是此道理。C的单元测试集实际上就是一个个可执行程序，每个程序的返回值都是需要认真考量的，不能随意。如果你使用类似lcut这样的框架工具，你就完全可以通过框架工具来帮你完成用例执行返回值的设定。

良好的项目构建设计是项目迈向成功的重要一步。在日常开发工作中我们不仅仅要关注软件开发过程中的"前段"，比如需求、设计和编码；对"后段"的一些活动，诸如构建、测试和部署也要给予足够的关注。以上所讲仅是经验之谈，谈不上绝对正确，因为关于C应用构建的资料相对较少，也没有统一的标准，这里权当抛砖引玉了。

restrict关键字是C99标准中新引入的一个类型修饰符(type qualifier)。如果你看过GNU C库的源码或是其manual，你就会发现restrict修饰符被广泛地应用在GNU C库中。restrict关键字到底是用来做什么的呢？估计很多对C语言细节研究不够的程序员都无法给出答案，我个人也只是停留在"知道"这一关键字的层次上，于是乎今天我又对着C99规范钻研了一番，略有收获，这里也说道说道。

为何C标准委员会要在C99标准中引入restrict呢？这当然是有历史原因的。我们先来看看下面这个例子：
/* foo.c */
void foo(int *p, int *q, int *r) {
    *p += *r;
    *q += *r ;
}

int main() {
    int a = 1;
    int b = 2;
    int c = 3;
    foo(&a, &b, &c);
}

C语言的设计哲学之一就是性能至上，为了性能可以舍弃一切。C程序员都希望编译器能为自己编写的程序生成高性能的目标代码，我们现在就来看看GCC编译器(在优化开关-O2已打开的情况下)为这段程序生成的目标代码是什么样子的。

我们通过GDB对函数foo进行反汇编，结果如下：

(gdb) disas foo
Dump of assembler code for function foo:
   0x080483c0 :    push   %ebp
   0x080483c1 :    mov    %esp,%ebp
   0x080483c3 :    mov    0×10(%ebp),%edx 
   0x080483c6 :    mov    0×8(%ebp),%ecx  
   0x080483c9 :    mov    0xc(%ebp),%eax  
   0x080483cc :    push   %ebx
   0x080483cd :    mov    (%edx),%ebx 
   0x080483cf :    add    %ebx,(%ecx) 
   0x080483d1 :    mov    (%edx),%edx 
   0x080483d3 :    add    %edx,(%eax) 
   0x080483d5 :    pop    %ebx
   0x080483d6 :    pop    %ebp
   0x080483d7 :    ret   
End of assembler dump.

这段汇编代码不是很难，我们将关键部分抽取出来并在每行汇编码后面给出解释：
mov    0×10(%ebp),%edx  ; r -> %edx，将指针r指向的内存对象的地址放入寄存器edx
mov    0×8(%ebp),%ecx   ; p -> %ecx，将指针p指向的内存对象的地址放入寄存器ecx
mov    0xc(%ebp),%eax   ; q -> %eax，将指针q指向的内存对象的地址放入寄存器eax
push   %ebx
mov    (%edx),%ebx  ; *r -> %ebx，将指针r指向的内存对象的值加载到寄存器ebx中
add    %ebx,(%ecx)  ; *r + *p -> *p， 将寄存器ebx中的数值与指针p所指内存对象的值相加，结果存放在指针p所指的内存对象中
mov    (%edx),%edx  ; *r -> %edx，将指针r指向的内存对象的值加载到寄存器edx中
add    %edx,(%eax)  ; *r + *q -> *q，将寄存器edx中的数值与指针q所指内存对象的值相加，结果存放在指针q所指的内存对象中

这段汇编代码是否是经过优化过的呢？我们结合foo函数的源代码分析后可以发现生成的目标码并非是经过优化的。在foo函数中指针r指向的内存对象一直都作为右值，其值没有被改动，编译器在第二次加法操作中完全可以直接利用第一次加载*r值的寄存器，而不是重新从内存中加载*r。但编译器为何没有优化掉这次访存操作呢？原因就在于编译器凭借C源代码中已有的信息是无法作出这种优化决策的。因为当编译器在foo的实现的上下文中看到三个指针时，它并不能判断出这三个指针所指向的地址是否有重叠，也就是说编译器并不能确定在第二次加法操作之前，r指向的内存对象是否被改变，编译器只能中规中矩地生成未经优化的目标代码，即每次都重新加载*r到寄存器，否则擅自优化会导致一些不可预期的行为。

那如何能帮助编译器作出正确的优化决策呢？这就需要程序员显式地为编译器提供用于决策的信息。在C99以前，很多编译器通过提供#Pragma参数或自扩展的关键字来实现这一点。比如：GCC为程序员提供了__restrict__或__restrict扩展关键字，有了这些关键字后，C程序员就可以显式地向编译器传达信息了。还以foo为例，我们看看加上__restrict__后编译器为函数foo生成的目标代码是什么样子的：

void foo(int *__restrict__ p, int *__restrict__ q, int * __restrict__r) {
    *p += *r;
    *q += *r ;
}

(gdb) disas foo
Dump of assembler code for function foo:
   0x080483c0 :    push   %ebp
   0x080483c1 :    mov    %esp,%ebp
   0x080483c3 :    mov    0×10(%ebp),%edx
   0x080483c6 :    mov    0×8(%ebp),%ecx
   0x080483c9 :    mov    0xc(%ebp),%eax
   0x080483cc :    mov    (%edx),%edx
   0x080483ce :    add    %edx,(%ecx)
   0x080483d0 :    add    %edx,(%eax)
   0x080483d2 :    pop    %ebp
   0x080483d3 :    ret   
End of assembler dump.

我们主要来看下面连续的三行汇编代码：
0x080483cc :    mov    (%edx),%edx ; *r -> %edx，将指针r指向的内存对象的值加载到寄存器edx中
0x080483ce :    add    %edx,(%ecx) ; *r + *p -> *p，将寄存器edx中的数值与指针p所指内存对象的值相加，结果存放在指针p所指的内存对象中
0x080483d0 :    add    %edx,(%eax) ; *r + *q -> *q，将寄存器edx中的数值与指针q所指内存对象的值相加，结果存放在指针q所指的内存对象中

可以看到这次编译器生成了优化后的代码，第二次加法操作直接用的是缓存在寄存器中的*r值。以上就是C99引入restrict关键字的一个基本考虑，通过restrict，C程序员可以告知编译器大胆地去执行优化，程序员来保证代码符合restrict语义的约束要求，这可以看作是一种程序员与编译器间的契约。

前面说过restrict是一种类型修饰符，但不同于其他两种修饰符const和volatile，restrict仅用于修饰指针类型与不完整类型(incomplete types)，C99规范中对restrict的诠释是这样的："Types other than pointer types derived from object or incomplete types shall not be restrict-qualified"。用restrict修饰指针是最常见的情况，被restrict修饰的指针到底有何与众不同呢？

用restrict修饰某指针变量意味着在该指针变量的生命周期内，该指针是其所指内存对象的唯一访问和修改入口，即所有对其所指的内存对象数据的访问和修改都是通过该指针完成的。或是说在特定上下文中该指针所指的内存对象不存在别名(Alias)。何为别名？引用同一内存对象的多个变量互为别名。比如：
int a = 5;
int *p = &a;
int *q = p;

这样p, q, a互为别名，它们都引用到地址&a。另外如果两个指针所指向的内存对象有相互重叠，那相互也算做是一种别名。

restrict的语义约束可以分成两个方面，一个是对内部的，一个是对外部的。我们还以上面的foo函数为例，这里稍作改动，去掉p，q两个参数的restrict修饰：

void foo(int *p, int *q, int *restrict r) {
    *p += *r;
    *q += *r ;
}

从foo内部来看，r是一个被restrict修饰的指针，其生命周期从foo执行开始一直到foo执行结束。按照上面对restrict的诠释，在foo函数内部不应该存在指针r所指内存对象的别名，即不应该存在下面情况：

void foo(int *p, int *q, int *restrict r) {
    int *z = r;
    …later, use r and z…
}

这的约束是foo的实现者保证的。

对于外部而言，即foo的使用者依然要保证传入实参后p或q不是r所指内存对象的别名，下面这样的代码将违反约束：
int a = 5;
int b = 6;
foo(&a, &b, &b);

这里还有一个问题：虽然r用了restrict修饰符，但编译器在看到void foo(int *p, int *q, int *restrict r)这个函数原型后就一定会生成优化的代码吗？显然通过这个原型信息，编译器依旧无法保证p或q不是r所指内存地址的别名，所以对上面这段代码编译器无法给出优化，即使r是被restrict修饰的，至少在我的Ubuntu gcc 4.4.3上是不会生成优化目标代码的。也就是说这个例子中foo的设计者与编译器之间的契约不够充分，无法让Compiler完全信服地去执行优化。这就需要进一步的补充契约，也就是让Compiler意识到p, q, r在foo中都是各自所指内存地址的唯一入口，为了达到这一点，我们只能为p, q也加上restrict修饰，这样契约变成foo内部的p, q, r是给自所指内存的唯一入口，p, q, r也就不可能是对方的别名了。

但即使所有指针参数都加上restrict修饰，Compiler就一定会生成优化的代码吗，事实是也不一定。看下面例子：
void foo1(int *restrict p, int *restrict q, char *restrict r) {
    *p += (int)*r;
    *q += (int)*r;
}
void foo2(int *restrict p, int *restrict q, long long int *restrict r) {
    *p += (int)*r;
    *q += (int)*r;
}

可以看到我们分别将foo函数的最后一个参数r的类型换为了char*和long long int*并,形成两个函数foo1和foo2，我们尝试用GCC生成对应的目标代码，通过反编译，我们可以得到如下结果：

(gdb) disas foo1
Dump of assembler code for function foo1:
   0×08048430 :    push   %ebp
   0×08048431 :    mov    %esp,%ebp
   0×08048433 :    mov    0×10(%ebp),%edx
   0×08048436 :    mov    0×8(%ebp),%ecx
   0×08048439 :    mov    0xc(%ebp),%eax
   0x0804843c :    push   %ebx
   0x0804843d :    movsbl (%edx),%ebx
   0×08048440 :    add    %ebx,(%ecx)
   0×08048442 :    movsbl (%edx),%edx
   0×08048445 :    add    %edx,(%eax)
   0×08048447 :    pop    %ebx
   0×08048448 :    pop    %ebp
   0×08048449 :    ret   
End of assembler dump.

(gdb) disas foo2
Dump of assembler code for function foo2:
   0×08048450 :    push   %ebp
   0×08048451 :    mov    %esp,%ebp
   0×08048453 :    mov    0×10(%ebp),%edx
   0×08048456 :    mov    0×8(%ebp),%ecx
   0×08048459 :    mov    0xc(%ebp),%eax
   0x0804845c :    mov    (%edx),%edx
   0x0804845e :    add    %edx,(%ecx)
   0×08048460 :    add    %edx,(%eax)
   0×08048462 :    pop    %ebp
   0×08048463 :    ret   
End of assembler dump.

我们可以看到GCC只为foo2生成了优化后的代码，而foo1并未被优化。这个结果让人有些摸不着头脑。难道编译器认为char*指针有成为int*指针所指对象的alias的潜在可能，而int*指针无法成为long long int*指针所指对象的alias？在C99规范中我也没能找到解释这一现象的答案。看来即使增加了restrict，编译器也是有选择的信任，至少Gcc是这样的。

restrict的作用范围与其修饰的指针的生命周期一致，你可以声明文件作用域(file scope)的restrict指针变量，也可以在某个代码block中使用restrict指针。如果某个结构体成员是restrict pointer类型，那该指针的生命周期就等同于该结构体实例的生命周期。

如果你恶意破坏你和Compiler之间的契约，别指望Compiler会有Warning提示，Compiler在这方面是完全信赖程序员的，不确定行为不可避免。比如：
void foo(int *restrict p, int *restrict q, int *restrict r) {
    *p += *r;
    *q += *r;
}

int main() {
    int a = 1;
    int b = 2;
    int c = 3;
    foo(&a, &b, &a);
    printf("a = %d, b = %d, c = %d\n", a, b, c);
}
执行优化后的程序，我们得到的输出为：
$ a.out
a = 2, b = 4, c = 3
这显然与预期的a = 2, b = 3, c = 3不符，错误原因就在于你单方面违反了restrict契约。

C99规范中对restrict关键字的讲解还算不少，甚至还给出了formal definition(C99 6.7.3.1)，不过这个定义简直就像一段天书，实在是晦涩难懂(《The New C Standard》一书对此有逐句的解释，不过依旧很难理解)。另外restrict的存在对程序本身的语义没有任何影响，对于不支持restrict的编译器也大可忽略restrict修饰符。

至于在平时开发中如何使用restrict，我个人觉得最好是在有一定理解的前提下使用。这对C程序员能力还是有一定要求的。首先要明确你编写的函数内部是否有可以优化的地方，如果根本没有可优化的潜力，那使用restrict就画蛇添足了；当然还有一种情况下你用restrict并不是期望编译器给予优化，而是你的实现算法是基于参数指针所指内存对象无alias的前提的，你在函数原型中用restrict修饰参数主要是想将你的意图告知该函数的使用者；第二要知道restrict对函数内部实现的约束，不要在内部实现时违反约束，导致未定义行为；第三如果你是一个使用者，面对采用了restrict修饰的函数接口，如void *memcpy(void * restrict s1, const void * restrict s2, size_t n)，你要注意不能违反restrict约束，否则也会导致未定义行为。如果你是一个公共库的开发者，你更应该尽量采用restrict，这对你的库代码的性能会是大有裨益的。