七种武器――.NET工程师求职面试必杀技
一、.NET框架（七种武器之孔雀翎）
开发人员应该熟悉.NET FrameWork体系结构和基本原理，熟悉CLR（公共语言运行时）和MSIL(中间语言)，熟悉.NET框架中的委托、线程、序列化、集合、垃圾回收机制、反射等内容。
（世界上绝没有一种暗器能比孔雀翎更厉害，也绝没有一种武器能比孔雀翎更美丽……孔雀翎娇小的身躯中隐藏着巨大的威力…….NET框架的博大精深，正如同孔雀翎一样美丽而深不可测。）
二、面向对象软件开发（七种武器之霸王枪）
开发人员应该熟悉面向对象软件开发(OOP)基本概念，熟悉面向对象软件开发中的类、继承、封装、多态等概念，具备良好的面向对象软件开发思想和设计原则。
（霸王，力拔山兮气盖世。枪，百兵之祖是为枪……霸王枪是世上最霸道的兵器之一……正如面向对象软件开发，它大小通吃，不论是采用何种软件开发框架，还是使用不同的开发语言，面向对象软件开发在其中畅通无阻，霸气十足。）
三、C# (七种武器之离别钩)
开发人员应该熟练掌握C#这门面向对象编程语言，虽然.NET框架支持多种编程语言，但C#无疑是最简洁、使用者最广泛和功能最强大的一种。
（离别钩是一件武器，无论钩住人的任何部位，都能造成离别……但使用它的初衷却是为了能够与所爱的人相聚……C#是一门年轻的语言，它的出现，让更多的开发者爱上了C#，脱离了VB和ASP的阵营，造成离别。）
四、ASP.NET（七种武器之碧玉刀）
开发人员应该理解ASP.NET的页面生命周期、熟悉配置文件的格式、熟悉ASP.NET的各种服务器控件和数据控件、了解ASP.NET中的各种对象，了解ASP.NET2.0新特性。
（刀是最容易上手的武器，也是使用最广泛的武器……ASP.NET技术在网站开发当中的应用，正如同刀一样地使用频繁，更何况是一把华丽的碧玉刀。碧玉刀本身也是实力的象征，就如同ASP.NET在WEB开发中的位置。）
五、数据库(七种武器之长生剑)
开发人员需了解各种主流数据库，熟悉数据库的规范设计、精通SQL及存储过程、触发器的编写。
（长生剑，世上最锋利的剑，剑气威力强大而又持续不断、绵绵不息……正如同数据库一样，吸纳吞吐，化大象于无形，强力支撑着软件系统。要想在IT界获得长生，就看你数据库的功底了。）
六、AJAX技术(JAVASCRIPT和XML)(七种武器之多情环)
XML和JAVASCRIPT的跨平台特性，在实际软件开发中的运用越来越广泛，由于现代软件对用户界面和WEB前端的日益重视，集JAVASCRIPT和XML技术于大成的AJAX正在流行，特别是在基于WEB2.0的网站开发中。
（多情环是一种奇特的武器。无论套住了什么，立刻就紧紧地缠住，绝不会再脱手，就像多情的恋人一样……JAVASCRIPT和XML技术已经出现多年，此前一直不痛不痒，但由于集JAVASCRIPT和XML于大成的AJAX技术的出现及其在互联网上的不断应用，又重新焕发出生命活力，就像多情的环一样，将众多的开发者牢牢系住，在2006年红透了整个IT界，2007年AJAX技术将继续红火。）
七、软件体系架构(拳头)
优秀的软件离不开优秀的软件体系架构，作为开发人员，要想在IT行业更进一步，需要具备系统的、良好的软件体系架构思维，从而从更高层次决定软件的整体系统框架。
（拳头也是一种武器。而且是无可替代的武器。当分散的五指握成拳头，它的力量又岂仅仅是原来的五倍……优良的软件体系架构是整个软件开发体系的核心，就如同拳头一样，它是直接而致命的。但有一点，不是每个人的拳头都可以用做武器的。）
结束语：无论多可怕的武器，也比不上人类的信心。所以人类最厉害的武器。便是自己的信心。相信你自己，做最好的自己，你就会成功！
2009年3月29日星期日
Makefile
http://topic.csdn.net/u/20070720/09/79922fb0-bbd6-403c-bba3-3c9bc8c71368.html
0 Makefile概述
--------------------------------------------------------------------------------
什么是makefile？或许很多Winodws的程序员都不知道这个东西，因为那些Windows的IDE都为你做了这个工作，但我觉得要作一个好的和 professional的程序员，makefile还是要懂。这就好像现在有这么多的HTML的编辑器，但如果你想成为一个专业人士，你还是要了解 HTML的标识的含义。特别在Unix下的软件编译，你就不能不自己写makefile了，会不会写makefile，从一个侧面说明了一个人是否具备完成大型工程的能力。
因为，makefile关系到了整个工程的编译规则。一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作，因为makefile就像一个Shell 脚本一样，其中也可以执行操作系统的命令。
makefile带来的好处就是――"自动化编译"，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。
现在讲述如何写makefile的文章比较少，这是我想写这篇文章的原因。当然，不同产商的make各不相同，也有不同的语法，但其本质都是在"文件依赖性"上做文章，这里，我仅对GNU的make进行讲述，我的环境是RedHat Linux 8.0，make的版本是3.80。必竟，这个make是应用最为广泛的，也是用得最多的。而且其还是最遵循于IEEE 1003.2-1992 标准的（POSIX.2）。
在这篇文档中，将以C/C++的源码作为我们基础，所以必然涉及一些关于C/C++的编译的知识，相关于这方面的内容，还请各位查看相关的编译器的文档。这里所默认的编译器是UNIX下的GCC和CC。
0.1 关于程序的编译和链接
在此，我想多说关于程序编译的一些规范和方法，一般来说，无论是C、C++、还是pas，首先要把源文件编译成中间代码文件，在Windows下也就是 .obj 文件，UNIX下是 .o 文件，即 Object File，这个动作叫做编译（compile）。然后再把大量的Object File合成执行文件，这个动作叫作链接（link）。
编译时，编译器需要的是语法的正确，函数与变量的声明的正确。对于后者，通常是你需要告诉编译器头文件的所在位置（头文件中应该只是声明，而定义应该放在 C/C++文件中），只要所有的语法正确，编译器就可以编译出中间目标文件。一般来说，每个源文件都应该对应于一个中间目标文件（O文件或是OBJ文件）。
链接时，主要是链接函数和全局变量，所以，我们可以使用这些中间目标文件（O文件或是OBJ文件）来链接我们的应用程序。链接器并不管函数所在的源文件，只管函数的中间目标文件（Object File），在大多数时候，由于源文件太多，编译生成的中间目标文件太多，而在链接时需要明显地指出中间目标文件名，这对于编译很不方便，所以，我们要给中间目标文件打个包，在Windows下这种包叫"库文件"（Library File)，也就是 .lib 文件，在UNIX下，是Archive File，也就是 .a 文件。
总结一下，源文件首先会生成中间目标文件，再由中间目标文件生成执行文件。在编译时，编译器只检测程序语法，和函数、变量是否被声明。如果函数未被声明，编译器会给出一个警告，但可以生成Object File。而在链接程序时，链接器会在所有的Object File中找寻函数的实现，如果找不到，那到就会报链接错误码（Linker Error），在VC下，这种错误一般是：Link 2001错误，意思说是说，链接器未能找到函数的实现。你需要指定函数的Object File.
好，言归正传，GNU的make有许多的内容，闲言少叙，还是让我们开始吧。
1 Makefile 介绍
--------------------------------------------------------------------------------
make命令执行时，需要一个 Makefile 文件，以告诉make命令需要怎么样的去编译和链接程序。
首先，我们用一个示例来说明Makefile的书写规则。以便给大家一个感兴认识。这个示例来源于GNU的make使用手册，在这个示例中，我们的工程有 8个C文件，和3个头文件，我们要写一个Makefile来告诉make命令如何编译和链接这几个文件。我们的规则是：
如果这个工程没有编译过，那么我们的所有C文件都要编译并被链接。
如果这个工程的某几个C文件被修改，那么我们只编译被修改的C文件，并链接目标程序。
如果这个工程的头文件被改变了，那么我们需要编译引用了这几个头文件的C文件，并链接目标程序。
只要我们的Makefile写得够好，所有的这一切，我们只用一个make命令就可以完成，make命令会自动智能地根据当前的文件修改的情况来确定哪些文件需要重编译，从而自己编译所需要的文件和链接目标程序。
1.1 Makefile的规则
在讲述这个Makefile之前，还是让我们先来粗略地看一看Makefile的规则。
target ... : prerequisites ...
command
...
...
target也就是一个目标文件，可以是Object File，也可以是执行文件。还可以是一个标签（Label），对于标签这种特性，在后续的"伪目标"章节中会有叙述。
prerequisites就是，要生成那个target所需要的文件或是目标。
command也就是make需要执行的命令。（任意的Shell命令）
这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说，prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。这就是 Makefile的规则。也就是Makefile中最核心的内容。
说到底，Makefile的东西就是这样一点，好像我的这篇文档也该结束了。呵呵。还不尽然，这是Makefile的主线和核心，但要写好一个Makefile还不够，我会以后面一点一点地结合我的工作经验给你慢慢到来。内容还多着呢。：）
1.2 一个示例
正如前面所说的，如果一个工程有3个头文件，和8个C文件，我们为了完成前面所述的那三个规则，我们的Makefile应该是下面的这个样子的。
edit : main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
cc -o edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean :
rm edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
反斜杠（\）是换行符的意思。这样比较便于Makefile的易读。我们可以把这个内容保存在文件为"Makefile"或"makefile"的文件中，然后在该目录下直接输入命令"make"就可以生成执行文件edit。如果要删除执行文件和所有的中间目标文件，那么，只要简单地执行一下"make clean"就可以了。
在这个makefile中，目标文件（target）包含：执行文件edit和中间目标文件（*.o），依赖文件（prerequisites）就是冒号后面的那些 .c 文件和 .h文件。每一个 .o 文件都有一组依赖文件，而这些 .o 文件又是执行文件 edit 的依赖文件。依赖关系的实质上就是说明了目标文件是由哪些文件生成的，换言之，目标文件是哪些文件更新的。
在定义好依赖关系后，后续的那一行定义了如何生成目标文件的操作系统命令，一定要以一个Tab键作为开头。记住，make并不管命令是怎么工作的，他只管执行所定义的命令。make会比较targets文件和prerequisites文件的修改日期，如果prerequisites文件的日期要比 targets文件的日期要新，或者target不存在的话，那么，make就会执行后续定义的命令。
这里要说明一点的是，clean不是一个文件，它只不过是一个动作名字，有点像C语言中的lable一样，其冒号后什么也没有，那么，make就不会自动去找文件的依赖性，也就不会自动执行其后所定义的命令。要执行其后的命令，就要在make命令后明显得指出这个lable的名字。这样的方法非常有用，我们可以在一个makefile中定义不用的编译或是和编译无关的命令，比如程序的打包，程序的备份，等等。
1.3 make是如何工作的
在默认的方式下，也就是我们只输入make命令。那么，
make会在当前目录下找名字叫"Makefile"或"makefile"的文件。
如果找到，它会找文件中的第一个目标文件（target），在上面的例子中，他会找到"edit"这个文件，并把这个文件作为最终的目标文件。
如果edit文件不存在，或是edit所依赖的后面的 .o 文件的文件修改时间要比edit这个文件新，那么，他就会执行后面所定义的命令来生成edit这个文件。
如果edit所依赖的.o文件也存在，那么make会在当前文件中找目标为.o文件的依赖性，如果找到则再根据那一个规则生成.o文件。（这有点像一个堆栈的过程）
当然，你的C文件和H文件是存在的啦，于是make会生成 .o 文件，然后再用 .o 文件生命make的终极任务，也就是执行文件edit了。
这就是整个make的依赖性，make会一层又一层地去找文件的依赖关系，直到最终编译出第一个目标文件。在找寻的过程中，如果出现错误，比如最后被依赖的文件找不到，那么make就会直接退出，并报错，而对于所定义的命令的错误，或是编译不成功，make根本不理。make只管文件的依赖性，即，如果在我找了依赖关系之后，冒号后面的文件还是不在，那么对不起，我就不工作啦。
通过上述分析，我们知道，像clean这种，没有被第一个目标文件直接或间接关联，那么它后面所定义的命令将不会被自动执行，不过，我们可以显示要make执行。即命令――"make clean"，以此来清除所有的目标文件，以便重编译。
于是在我们编程中，如果这个工程已被编译过了，当我们修改了其中一个源文件，比如file.c，那么根据我们的依赖性，我们的目标file.o会被重编译（也就是在这个依性关系后面所定义的命令），于是file.o的文件也是最新的啦，于是file.o的文件修改时间要比edit要新，所以edit也会被重新链接了（详见edit目标文件后定义的命令）。
而如果我们改变了"command.h"，那么，kdb.o、command.o和files.o都会被重编译，并且，edit会被重链接。
1.4 makefile中使用变量
在上面的例子中，先让我们看看edit的规则：
edit : main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
cc -o edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
我们可以看到[.o]文件的字符串被重复了两次，如果我们的工程需要加入一个新的[.o]文件，那么我们需要在两个地方加（应该是三个地方，还有一个地方在clean中）。当然，我们的makefile并不复杂，所以在两个地方加也不累，但如果makefile变得复杂，那么我们就有可能会忘掉一个需要加入的地方，而导致编译失败。所以，为了makefile的易维护，在makefile中我们可以使用变量。makefile的变量也就是一个字符串，理解成C语言中的宏可能会更好。
比如，我们声明一个变量，叫objects, OBJECTS, objs, OBJS, obj, 或是 OBJ，反正不管什么啦，只要能够表示obj文件就行了。我们在makefile一开始就这样定义：
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
于是，我们就可以很方便地在我们的makefile中以"$(objects)"的方式来使用这个变量了，于是我们的改良版makefile就变成下面这个样子：
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean :
rm edit $(objects)
于是如果有新的 .o 文件加入，我们只需简单地修改一下 objects 变量就可以了。
关于变量更多的话题，我会在后续给你一一道来。
1.5 让make自动推导
GNU的make很强大，它可以自动推导文件以及文件依赖关系后面的命令，于是我们就没必要去在每一个[.o]文件后都写上类似的命令，因为，我们的make会自动识别，并自己推导命令。
只要make看到一个[.o]文件，它就会自动的把[.c]文件加在依赖关系中，如果make找到一个whatever.o，那么whatever.c，就会是whatever.o的依赖文件。并且 cc -c whatever.c 也会被推导出来，于是，我们的makefile再也不用写得这么复杂。我们的是新的makefile又出炉了。
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : defs.h
kbd.o : defs.h command.h
command.o : defs.h command.h
display.o : defs.h buffer.h
insert.o : defs.h buffer.h
search.o : defs.h buffer.h
files.o : defs.h buffer.h command.h
utils.o : defs.h
.PHONY : clean
clean :
rm edit $(objects)
这种方法，也就是make的"隐晦规则"。上面文件内容中，".PHONY"表示，clean是个伪目标文件。
关于更为详细的"隐晦规则"和"伪目标文件"，我会在后续给你一一道来。
1.6 另类风格的makefile
即然我们的make可以自动推导命令，那么我看到那堆[.o]和[.h]的依赖就有点不爽，那么多的重复的[.h]，能不能把其收拢起来，好吧，没有问题，这个对于make来说很容易，谁叫它提供了自动推导命令和文件的功能呢？来看看最新风格的makefile吧。
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
$(objects) : defs.h
kbd.o command.o files.o : command.h
display.o insert.o search.o files.o : buffer.h
.PHONY : clean
clean :
rm edit $(objects)
这种风格，让我们的makefile变得很简单，但我们的文件依赖关系就显得有点凌乱了。鱼和熊掌不可兼得。还看你的喜好了。我是不喜欢这种风格的，一是文件的依赖关系看不清楚，二是如果文件一多，要加入几个新的.o文件，那就理不清楚了。
1.7 清空目标文件的规则
每个Makefile中都应该写一个清空目标文件（.o和执行文件）的规则，这不仅便于重编译，也很利于保持文件的清洁。这是一个"修养"（呵呵，还记得我的《编程修养》吗）。一般的风格都是：
clean:
rm edit $(objects)
更为稳健的做法是：
.PHONY : clean
clean :
-rm edit $(objects)
前面说过，.PHONY意思表示clean是一个"伪目标"，。而在rm命令前面加了一个小减号的意思就是，也许某些文件出现问题，但不要管，继续做后面的事。当然，clean的规则不要放在文件的开头，不然，这就会变成make的默认目标，相信谁也不愿意这样。不成文的规矩是――"clean从来都是放在文件的最后"。
上面就是一个makefile的概貌，也是makefile的基础，下面还有很多makefile的相关细节，准备好了吗？准备好了就来。
2 Makefile 总述
2.1 Makefile里有什么？
Makefile里主要包含了五个东西：显式规则、隐晦规则、变量定义、文件指示和注释。
显式规则。显式规则说明了，如何生成一个或多的的目标文件。这是由Makefile的书写者明显指出，要生成的文件，文件的依赖文件，生成的命令。
隐晦规则。由于我们的make有自动推导的功能，所以隐晦的规则可以让我们比较粗糙地简略地书写Makefile，这是由make所支持的。
变量的定义。在Makefile中我们要定义一系列的变量，变量一般都是字符串，这个有点你C语言中的宏，当Makefile被执行时，其中的变量都会被扩展到相应的引用位置上。
文件指示。其包括了三个部分，一个是在一个Makefile中引用另一个Makefile，就像C语言中的include一样；另一个是指根据某些情况指定Makefile中的有效部分，就像C语言中的预编译#if一样；还有就是定义一个多行的命令。有关这一部分的内容，我会在后续的部分中讲述。
注释。Makefile中只有行注释，和UNIX的Shell脚本一样，其注释是用"#"字符，这个就像C/C++中的"//"一样。如果你要在你的Makefile中使用"#"字符，可以用反斜框进行转义，如："\#"。
最后，还值得一提的是，在Makefile中的命令，必须要以[Tab]键开始。
2.2Makefile的文件名
默认的情况下，make命令会在当前目录下按顺序找寻文件名为"GNUmakefile"、"makefile"、"Makefile"的文件，找到了解释这个文件。在这三个文件名中，最好使用"Makefile"这个文件名，因为，这个文件名第一个字符为大写，这样有一种显目的感觉。最好不要用 "GNUmakefile"，这个文件是GNU的make识别的。有另外一些make只对全小写的"makefile"文件名敏感，但是基本上来说，大多数的make都支持"makefile"和"Makefile"这两种默认文件名。
当然，你可以使用别的文件名来书写Makefile，比如："Make.Linux"，"Make.Solaris"，"Make.AIX"等，如果要指定特定的Makefile，你可以使用make的"-f"和"--file"参数，如：make -f Make.Linux或make --file Make.AIX。
2.3 引用其它的Makefile
在Makefile使用include关键字可以把别的Makefile包含进来，这很像C语言的#include，被包含的文件会原模原样的放在当前文件的包含位置。include的语法是：
include <filename>filename可以是当前操作系统Shell的文件模式（可以保含路径和通配符）
在include前面可以有一些空字符，但是绝不能是[Tab]键开始。include和可以用一个或多个空格隔开。举个例子，你有这样几个 Makefile：a.mk、b.mk、c.mk，还有一个文件叫foo.make，以及一个变量$(bar)，其包含了e.mk和f.mk，那么，下面的语句：
include foo.make *.mk $(bar)
等价于：
include foo.make a.mk b.mk c.mk e.mk f.mk
make命令开始时，会把找寻include所指出的其它Makefile，并把其内容安置在当前的位置。就好像C/C++的#include指令一样。如果文件都没有指定绝对路径或是相对路径的话，make会在当前目录下首先寻找，如果当前目录下没有找到，那么，make还会在下面的几个目录下找：
如果make执行时，有"-I"或"--include-dir"参数，那么make就会在这个参数所指定的目录下去寻找。
如果目录/include（一般是：/usr/local/bin或/usr/include）存在的话，make也会去找。
如果有文件没有找到的话，make会生成一条警告信息，但不会马上出现致命错误。它会继续载入其它的文件，一旦完成makefile的读取，make会再重试这些没有找到，或是不能读取的文件，如果还是不行，make才会出现一条致命信息。如果你想让make不理那些无法读取的文件，而继续执行，你可以在 include前加一个减号"-"。如：
-include <filename>其表示，无论include过程中出现什么错误，都不要报错继续执行。和其它版本make兼容的相关命令是sinclude，其作用和这一个是一样的。
2.4 环境变量 MAKEFILES
如果你的当前环境中定义了环境变量MAKEFILES，那么，make会把这个变量中的值做一个类似于include的动作。这个变量中的值是其它的 Makefile，用空格分隔。只是，它和include不同的是，从这个环境变中引入的Makefile的"目标"不会起作用，如果环境变量中定义的文件发现错误，make也会不理。
但是在这里我还是建议不要使用这个环境变量，因为只要这个变量一被定义，那么当你使用make时，所有的Makefile都会受到它的影响，这绝不是你想看到的。在这里提这个事，只是为了告诉大家，也许有时候你的Makefile出现了怪事，那么你可以看看当前环境中有没有定义这个变量。
2.5 make的工作方式
GNU的make工作时的执行步骤入下：（想来其它的make也是类似）
读入所有的Makefile。
读入被include的其它Makefile。
初始化文件中的变量。
推导隐晦规则，并分析所有规则。
为所有的目标文件创建依赖关系链。
根据依赖关系，决定哪些目标要重新生成。
执行生成命令。
1-5步为第一个阶段，6-7为第二个阶段。第一个阶段中，如果定义的变量被使用了，那么，make会把其展开在使用的位置。但make并不会完全马上展开，make使用的是拖延战术，如果变量出现在依赖关系的规则中，那么仅当这条依赖被决定要使用了，变量才会在其内部展开。
当然，这个工作方式你不一定要清楚，但是知道这个方式你也会对make更为熟悉。有了这个基础，后续部分也就容易看懂了。
3 Makefile书写规则
--------------------------------------------------------------------------------
规则包含两个部分，一个是依赖关系，一个是生成目标的方法。
在Makefile中，规则的顺序是很重要的，因为，Makefile中只应该有一个最终目标，其它的目标都是被这个目标所连带出来的，所以一定要让 make知道你的最终目标是什么。一般来说，定义在Makefile中的目标可能会有很多，但是第一条规则中的目标将被确立为最终的目标。如果第一条规则中的目标有很多个，那么，第一个目标会成为最终的目标。make所完成的也就是这个目标。
好了，还是让我们来看一看如何书写规则。
3.1 规则举例
foo.o : foo.c defs.h # foo模块
cc -c -g foo.c
看到这个例子，各位应该不是很陌生了，前面也已说过，foo.o是我们的目标，foo.c和defs.h是目标所依赖的源文件，而只有一个命令"cc -c -g foo.c"（以Tab键开头）。这个规则告诉我们两件事：
文件的依赖关系，foo.o依赖于foo.c和defs.h的文件，如果foo.c和defs.h的文件日期要比foo.o文件日期要新，或是foo.o不存在，那么依赖关系发生。
如果生成（或更新）foo.o文件。也就是那个cc命令，其说明了，如何生成foo.o这个文件。（当然foo.c文件include了defs.h文件）
3.2 规则的语法
targets : prerequisites
command
...
或是这样：
targets : prerequisites ; command
command
...
targets是文件名，以空格分开，可以使用通配符。一般来说，我们的目标基本上是一个文件，但也有可能是多个文件。
command是命令行，如果其不与"target:prerequisites"在一行，那么，必须以[Tab键]开头，如果和prerequisites在一行，那么可以用分号做为分隔。（见上）
prerequisites也就是目标所依赖的文件（或依赖目标）。如果其中的某个文件要比目标文件要新，那么，目标就被认为是"过时的"，被认为是需要重生成的。这个在前面已经讲过了。
如果命令太长，你可以使用反斜框（'\'）作为换行符。make对一行上有多少个字符没有限制。规则告诉make两件事，文件的依赖关系和如何成成目标文件。
一般来说，make会以UNIX的标准Shell，也就是/bin/sh来执行命令。
3.3 在规则中使用通配符
如果我们想定义一系列比较类似的文件，我们很自然地就想起使用通配符。make支持三各通配符："*"，"?"和"[...]"。这是和Unix的B-Shell是相同的。
波浪号（"~"）字符在文件名中也有比较特殊的用途。如果是"~/test"，这就表示当前用户的$HOME目录下的test目录。而"~hchen /test"则表示用户hchen的宿主目录下的test目录。（这些都是Unix下的小知识了，make也支持）而在Windows或是MS-DOS 下，用户没有宿主目录，那么波浪号所指的目录则根据环境变量"HOME"而定。
通配符代替了你一系列的文件，如"*.c"表示所以后缀为c的文件。一个需要我们注意的是，如果我们的文件名中有通配符，如："*"，那么可以用转义字符"\"，如"\*"来表示真实的"*"字符，而不是任意长度的字符串。
好吧，还是先来看几个例子吧：
clean:
rm -f *.o
上面这个例子我不不多说了，这是操作系统Shell所支持的通配符。这是在命令中的通配符。
print: *.c
lpr -p $?
touch print
上面这个例子说明了通配符也可以在我们的规则中，目标print依赖于所有的[.c]文件。其中的"$?"是一个自动化变量，我会在后面给你讲述。
objects = *.o
上面这个例子，表示了，通符同样可以用在变量中。并不是说[*.o]会展开，不！objects的值就是"*.o"。Makefile中的变量其实就是 C/C++中的宏。如果你要让通配符在变量中展开，也就是让objects的值是所有[.o]的文件名的集合，那么，你可以这样：
objects := $(wildcard *.o)
这种用法由关键字"wildcard"指出，关于Makefile的关键字，我们将在后面讨论。
3.4 文件搜寻
在一些大的工程中，有大量的源文件，我们通常的做法是把这许多的源文件分类，并存放在不同的目录中。所以，当make需要去找寻文件的依赖关系时，你可以在文件前加上路径，但最好的方法是把一个路径告诉make，让make在自动去找。
Makefile文件中的特殊变量"VPATH"就是完成这个功能的，如果没有指明这个变量，make只会在当前的目录中去找寻依赖文件和目标文件。如果定义了这个变量，那么，make就会在当当前目录找不到的情况下，到所指定的目录中去找寻文件了。
VPATH = src:../headers
上面的的定义指定两个目录，"src"和"../headers"，make会按照这个顺序进行搜索。目录由"冒号"分隔。（当然，当前目录永远是最高优先搜索的地方）
另一个设置文件搜索路径的方法是使用make的"vpath"关键字（注意，它是全小写的），这不是变量，这是一个make的关键字，这和上面提到的那个 VPATH变量很类似，但是它更为灵活。它可以指定不同的文件在不同的搜索目录中。这是一个很灵活的功能。它的使用方法有三种：
vpath < pattern> < directories>
为符合模式 < pattern>的文件指定搜索目录 < directories>。
vpath < pattern>
清除符合模式 < pattern>的文件的搜索目录。
vpath
清除所有已被设置好了的文件搜索目录。
vapth使用方法中的 < pattern>需要包含"%"字符。"%"的意思是匹配零或若干字符，例如，"%.h"表示所有以".h"结尾的文件。 < pattern>指定了要搜索的文件集，而 < directories>则指定了的文件集的搜索的目录。例如：
vpath %.h ../headers
该语句表示，要求make在"../headers"目录下搜索所有以".h"结尾的文件。（如果某文件在当前目录没有找到的话）
我们可以连续地使用vpath语句，以指定不同搜索策略。如果连续的vpath语句中出现了相同的 < pattern>，或是被重复了的 < pattern>，那么，make会按照vpath语句的先后顺序来执行搜索。如：
vpath %.c foo
vpath % blish
vpath %.c bar
其表示".c"结尾的文件，先在"foo"目录，然后是"blish"，最后是"bar"目录。
vpath %.c foo:bar
vpath % blish
而上面的语句则表示".c"结尾的文件，先在"foo"目录，然后是"bar"目录，最后才是"blish"目录。
3.5 伪目标
最早先的一个例子中，我们提到过一个"clean"的目标，这是一个"伪目标"，
clean:
rm *.o temp
正像我们前面例子中的"clean"一样，即然我们生成了许多文件编译文件，我们也应该提供一个清除它们的"目标"以备完整地重编译而用。 （以"make clean"来使用该目标）
因为，我们并不生成"clean"这个文件。"伪目标"并不是一个文件，只是一个标签，由于"伪目标"不是文件，所以make无法生成它的依赖关系和决定它是否要执行。我们只有通过显示地指明这个"目标"才能让其生效。当然，"伪目标"的取名不能和文件名重名，不然其就失去了"伪目标"的意义了。
当然，为了避免和文件重名的这种情况，我们可以使用一个特殊的标记".PHONY"来显示地指明一个目标是"伪目标"，向make说明，不管是否有这个文件，这个目标就是"伪目标"。
.PHONY : clean
只要有这个声明，不管是否有"clean"文件，要运行"clean"这个目标，只有"make clean"这样。于是整个过程可以这样写：
.PHONY: clean
clean:
rm *.o temp
伪目标一般没有依赖的文件。但是，我们也可以为伪目标指定所依赖的文件。伪目标同样可以作为"默认目标"，只要将其放在第一个。一个示例就是，如果你的 Makefile需要一口气生成若干个可执行文件，但你只想简单地敲一个make完事，并且，所有的目标文件都写在一个Makefile中，那么你可以使用"伪目标"这个特性：
all : prog1 prog2 prog3
.PHONY : all
prog1 : prog1.o utils.o
cc -o prog1 prog1.o utils.o
prog2 : prog2.o
cc -o prog2 prog2.o
prog3 : prog3.o sort.o utils.o
cc -o prog3 prog3.o sort.o utils.o
我们知道，Makefile中的第一个目标会被作为其默认目标。我们声明了一个"all"的伪目标，其依赖于其它三个目标。由于伪目标的特性是，总是被执行的，所以其依赖的那三个目标就总是不如"all"这个目标新。所以，其它三个目标的规则总是会被决议。也就达到了我们一口气生成多个目标的目的。 ".PHONY : all"声明了"all"这个目标为"伪目标"。
随便提一句，从上面的例子我们可以看出，目标也可以成为依赖。所以，伪目标同样也可成为依赖。看下面的例子：
.PHONY: cleanall cleanobj cleandiff
cleanall : cleanobj cleandiff
rm program
cleanobj :
rm *.o
cleandiff :
rm *.diff
"make clean"将清除所有要被清除的文件。"cleanobj"和"cleandiff"这两个伪目标有点像"子程序"的意思。我们可以输入"make cleanall"和"make cleanobj"和"make cleandiff"命令来达到清除不同种类文件的目的
3.6 多目标
Makefile的规则中的目标可以不止一个，其支持多目标，有可能我们的多个目标同时依赖于一个文件，并且其生成的命令大体类似。于是我们就能把其合并起来。当然，多个目标的生成规则的执行命令是同一个，这可能会可我们带来麻烦，不过好在我们的可以使用一个自动化变量"$@"（关于自动化变量，将在后面讲述），这个变量表示着目前规则中所有的目标的集合，这样说可能很抽象，还是看一个例子吧。
bigoutput littleoutput : text.g
generate text.g -$(subst output,,$@) > $@
上述规则等价于：
bigoutput : text.g
generate text.g -big > bigoutput
littleoutput : text.g
generate text.g -little > littleoutput
其中，-$(subst output,,$@)中的"$"表示执行一个Makefile的函数，函数名为subst，后面的为参数。关于函数，将在后面讲述。这里的这个函数是截取字符串的意思，"$@"表示目标的集合，就像一个数组，"$@"依次取出目标，并执于命令。
3.7 静态模式
静态模式可以更加容易地定义多目标的规则，可以让我们的规则变得更加的有弹性和灵活。我们还是先来看一下语法：
<targets ...>: <target-pattern>: <prereq-patterns ...>
<commands>
...targets定义了一系列的目标文件，可以有通配符。是目标的一个集合。
target-parrtern是指明了targets的模式，也就是的目标集模式。
prereq-parrterns是目标的依赖模式，它对target-parrtern形成的模式再进行一次依赖目标的定义。
这样描述这三个东西，可能还是没有说清楚，还是举个例子来说明一下吧。如果我们的 <target-parrtern>定义成"%.o"，意思是我们的集合中都是以".o"结尾的，而如果我们的 <prereq-parrterns>定义成"%.c"，意思是对 <target-parrtern>所形成的目标集进行二次定义，其计算方法是，取 <target-parrtern>模式中的"%"（也就是去掉了[.o]这个结尾），并为其加上[.c]这个结尾，形成的新集合。
所以，我们的"目标模式"或是"依赖模式"中都应该有"%"这个字符，如果你的文件名中有"%"那么你可以使用反斜杠"\"进行转义，来标明真实的"%"字符。
看一个例子：
objects = foo.o bar.o
all: $(objects)
$(objects): %.o: %.c
$(CC) -c $(CFLAGS) $ < -o $@
上面的例子中，指明了我们的目标从$object中获取，"%.o"表明要所有以".o"结尾的目标，也就是"foo.o bar.o"，也就是变量$object集合的模式，而依赖模式"%.c"则取模式"%.o"的"%"，也就是"foo bar"，并为其加下".c"的后缀，于是，我们的依赖目标就是"foo.c bar.c"。而命令中的"$ <"和"$@"则是自动化变量，"$ <"表示所有的依赖目标集（也就是"foo.c bar.c"），"$@"表示目标集（也褪恰�oo.o bar.o"）。于是，上面的规则展开后等价于下面的规则：
foo.o : foo.c
$(CC) -c $(CFLAGS) foo.c -o foo.o
bar.o : bar.c
$(CC) -c $(CFLAGS) bar.c -o bar.o
试想，如果我们的"%.o"有几百个，那种我们只要用这种很简单的"静态模式规则"就可以写完一堆规则，实在是太有效率了。"静态模式规则"的用法很灵活，如果用得好，那会一个很强大的功能。再看一个例子：
files = foo.elc bar.o lose.o
$(filter %.o,$(files)): %.o: %.c
$(CC) -c $(CFLAGS) $ < -o $@
$(filter %.elc,$(files)): %.elc: %.el
emacs -f batch-byte-compile $ <
$(filter %.o,$(files))表示调用Makefile的filter函数，过滤"$filter"集，只要其中模式为"%.o"的内容。其的它内容，我就不用多说了吧。这个例字展示了Makefile中更大的弹性。
3.8 自动生成依赖性
在Makefile中，我们的依赖关系可能会需要包含一系列的头文件，比如，如果我们的main.c中有一句"#include "defs.h""，那么我们的依赖关系应该是：
main.o : main.c defs.h
但是，如果是一个比较大型的工程，你必需清楚哪些C文件包含了哪些头文件，并且，你在加入或删除头文件时，也需要小心地修改Makefile，这是一个很没有维护性的工作。为了避免这种繁重而又容易出错的事情，我们可以使用C/C++编译的一个功能。大多数的C/C++编译器都支持一个"-M"的选项，即自动找寻源文件中包含的头文件，并生成一个依赖关系。例如，如果我们执行下面的命令：
cc -M main.c
其输出是：
main.o : main.c defs.h
于是由编译器自动生成的依赖关系，这样一来，你就不必再手动书写若干文件的依赖关系，而由编译器自动生成了。需要提醒一句的是，如果你使用GNU的C/C++编译器，你得用"-MM"参数，不然，"-M"参数会把一些标准库的头文件也包含进来。
gcc -M main.c的输出是：
main.o: main.c defs.h /usr/include/stdio.h /usr/include/features.h \
/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \
/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/stddef.h \
/usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
/usr/include/bits/sched.h /usr/include/libio.h \
/usr/include/_G_config.h /usr/include/wchar.h \
/usr/include/bits/wchar.h /usr/include/gconv.h \
/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/stdarg.h \
/usr/include/bits/stdio_lim.h
gcc -MM main.c的输出则是：
main.o: main.c defs.h
那么，编译器的这个功能如何与我们的Makefile联系在一起呢。因为这样一来，我们的Makefile也要根据这些源文件重新生成，让 Makefile自已依赖于源文件？这个功能并不现实，不过我们可以有其它手段来迂回地实现这一功能。GNU组织建议把编译器为每一个源文件的自动生成的依赖关系放到一个文件中，为每一个"name.c"的文件都生成一个"name.d"的Makefile文件，[.d]文件中就存放对应[.c]文件的依赖关系。
于是，我们可以写出[.c]文件和[.d]文件的依赖关系，并让make自动更新或自成[.d]文件，并把其包含在我们的主Makefile中，这样，我们就可以自动化地生成每个文件的依赖关系了。
这里，我们给出了一个模式规则来产生[.d]文件：
%.d: %.c
@set -e; rm -f $@; \
$(CC) -M $(CPPFLAGS) $ < > $@.$$$$; \
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$
这个规则的意思是，所有的[.d]文件依赖于[.c]文件，"rm -f $@"的意思是删除所有的目标，也就是[.d]文件，第二行的意思是，为每个依赖文件"$ <"，也就是[.c]文件生成依赖文件，"$@"表示模式"%.d"文件，如果有一个C文件是name.c，那么"%"就是 "name"，"$$$$"意为一个随机编号，第二行生成的文件有可能是"name.d.12345"，第三行使用sed命令做了一个替换，关于sed命令的用法请参看相关的使用文档。第四行就是删除临时文件。
总而言之，这个模式要做的事就是在编译器生成的依赖关系中加入[.d]文件的依赖，即把依赖关系：
main.o : main.c defs.h
转成：
main.o main.d : main.c defs.h
于是，我们的[.d]文件也会自动更新了，并会自动生成了，当然，你还可以在这个[.d]文件中加入的不只是依赖关系，包括生成的命令也可一并加入，让每个[.d]文件都包含一个完赖的规则。一旦我们完成这个工作，接下来，我们就要把这些自动生成的规则放进我们的主Makefile中。我们可以使用 Makefile的"include"命令，来引入别的Makefile文件（前面讲过），例如：
sources = foo.c bar.c
include $(sources:.c=.d)
上述语句中的"$(sources:.c=.d)"中的".c=.d"的意思是做一个替换，把变量$(sources)所有[.c]的字串都替换成 [.d]，关于这个"替换"的内容，在后面我会有更为详细的讲述。当然，你得注意次序，因为include是按次来载入文件，最先载入的[.d]文件中的目标会成为默认目标.
4 Makefile 书写命令
--------------------------------------------------------------------------------
每条规则中的命令和操作系统Shell的命令行是一致的。make会一按顺序一条一条的执行命令，每条命令的开头必须以[Tab]键开头，除非，命令是紧跟在依赖规则后面的分号后的。在命令行之间中的空格或是空行会被忽略，但是如果该空格或空行是以Tab键开头的，那么make会认为其是一个空命令。
我们在UNIX下可能会使用不同的Shell，但是make的命令默认是被"/bin/sh"――UNIX的标准Shell解释执行的。除非你特别指定一个其它的Shell。Makefile中，"#"是注释符，很像C/C++中的"//"，其后的本行字符都被注释。
4.1 显示命令
通常，make会把其要执行的命令行在命令执行前输出到屏幕上。当我们用"@"字符在命令行前，那么，这个命令将不被make显示出来，最具代表性的例子是，我们用这个功能来像屏幕显示一些信息。如：
@echo 正在编译XXX模块......
当make执行时，会输出"正在编译XXX模块......"字串，但不会输出命令，如果没有"@"，那么，make将输出：
echo 正在编译XXX模块......
正在编译XXX模块......
如果make执行时，带入make参数"-n"或"--just-print"，那么其只是显示命令，但不会执行命令，这个功能很有利于我们调试我们的Makefile，看看我们书写的命令是执行起来是什么样子的或是什么顺序的。
而make参数"-s"或"--slient"则是全面禁止命令的显示。
4.2 命令执行
当依赖目标新于目标时，也就是当规则的目标需要被更新时，make会一条一条的执行其后的命令。需要注意的是，如果你要让上一条命令的结果应用在下一条命令时，你应该使用分号分隔这两条命令。比如你的第一条命令是cd命令，你希望第二条命令得在cd之后的基础上运行，那么你就不能把这两条命令写在两行上，而应该把这两条命令写在一行上，用分号分隔。如：
示例一：
exec:
cd /home/hchen
pwd
示例二：
exec:
cd /home/hchen; pwd
当我们执行"make exec"时，第一个例子中的cd没有作用，pwd会打印出当前的Makefile目录，而第二个例子中，cd就起作用了，pwd会打印出"/home/hchen"。
make一般是使用环境变量SHELL中所定义的系统Shell来执行命令，默认情况下使用UNIX的标准Shell――/bin/sh来执行命令。但在 MS-DOS下有点特殊，因为MS-DOS下没有SHELL环境变量，当然你也可以指定。如果你指定了UNIX风格的目录形式，首先，make会在 SHELL所指定的路径中找寻命令解释器，如果找不到，其会在当前盘符中的当前目录中寻找，如果再找不到，其会在PATH环境变量中所定义的所有路径中寻找。MS-DOS中，如果你定义的命令解释器没有找到，其会给你的命令解释器加上诸如".exe"、".com"、".bat"、".sh"等后缀。
4.3 命令出错
每当命令运行完后，make会检测每个命令的返回码，如果命令返回成功，那么make会执行下一条命令，当规则中所有的命令成功返回后，这个规则就算是成功完成了。如果一个规则中的某个命令出错了（命令退出码非零），那么make就会终止执行当前规则，这将有可能终止所有规则的执行。
有些时候，命令的出错并不表示就是错误的。例如mkdir命令，我们一定需要建立一个目录，如果目录不存在，那么mkdir就成功执行，万事大吉，如果目录存在，那么就出错了。我们之所以使用mkdir的意思就是一定要有这样的一个目录，于是我们就不希望mkdir出错而终止规则的运行。
为了做到这一点，忽略命令的出错，我们可以在Makefile的命令行前加一个减号"-"（在Tab键之后），标记为不管命令出不出错都认为是成功的。如：
clean:
-rm -f *.o
还有一个全局的办法是，给make加上"-i"或是"--ignore-errors"参数，那么，Makefile中所有命令都会忽略错误。而如果一个规则是以".IGNORE"作为目标的，那么这个规则中的所有命令将会忽略错误。这些是不同级别的防止命令出错的方法，你可以根据你的不同喜欢设置。
还有一个要提一下的make的参数的是"-k"或是"--keep-going"，这个参数的意思是，如果某规则中的命令出错了，那么就终目该规则的执行，但继续执行其它规则。
4.4 嵌套执行make
在一些大的工程中，我们会把我们不同模块或是不同功能的源文件放在不同的目录中，我们可以在每个目录中都书写一个该目录的Makefile，这有利于让我们的Makefile变得更加地简洁，而不至于把所有的东西全部写在一个Makefile中，这样会很难维护我们的Makefile，这个技术对于我们模块编译和分段编译有着非常大的好处。
例如，我们有一个子目录叫subdir，这个目录下有个Makefile文件，来指明了这个目录下文件的编译规则。那么我们总控的Makefile可以这样书写：
subsystem:
cd subdir && $(MAKE)
其等价于：
subsystem:
$(MAKE) -C subdir
定义$(MAKE)宏变量的意思是，也许我们的make需要一些参数，所以定义成一个变量比较利于维护。这两个例子的意思都是先进入"subdir"目录，然后执行make命令。
我们把这个Makefile叫做"总控Makefile"，总控Makefile的变量可以传递到下级的Makefile中（如果你显示的声明），但是不会覆盖下层的Makefile中所定义的变量，除非指定了"-e"参数。
如果你要传递变量到下级Makefile中，那么你可以使用这样的声明：
export <variable ...>
如果你不想让某些变量传递到下级Makefile中，那么你可以这样声明：
unexport <variable ...>
如：
示例一：
export variable = value
其等价于：
variable = value
export variable
其等价于：
export variable := value
其等价于：
variable := value
export variable
示例二：
export variable += value
其等价于：
variable += value
export variable
如果你要传递所有的变量，那么，只要一个export就行了。后面什么也不用跟，表示传递所有的变量。
需要注意的是，有两个变量，一个是SHELL，一个是MAKEFLAGS，这两个变量不管你是否export，其总是要传递到下层Makefile中，特别是MAKEFILES变量，其中包含了make的参数信息，如果我们执行"总控Makefile"时有make参数或是在上层Makefile中定义了这个变量，那么MAKEFILES变量将会是这些参数，并会传递到下层Makefile中，这是一个系统级的环境变量。
但是make命令中的有几个参数并不往下传递，它们是"-C","-f","-h""-o"和"-W"（有关Makefile参数的细节将在后面说明），如果你不想往下层传递参数，那么，你可以这样来：
subsystem:
cd subdir && $(MAKE) MAKEFLAGS=
如果你定义了环境变量MAKEFLAGS，那么你得确信其中的选项是大家都会用到的，如果其中有"-t","-n",和"-q"参数，那么将会有让你意想不到的结果，或许会让你异常地恐慌。
还有一个在"嵌套执行"中比较有用的参数，"-w"或是"--print-directory"会在make的过程中输出一些信息，让你看到目前的工作目录。比如，如果我们的下级make目录是"/home/hchen/gnu/make"，如果我们使用"make -w"来执行，那么当进入该目录时，我们会看到：
make: Entering directory `/home/hchen/gnu/make'.
而在完成下层make后离开目录时，我们会看到：
make: Leaving directory `/home/hchen/gnu/make'
当你使用"-C"参数来指定make下层Makefile时，"-w"会被自动打开的。如果参数中有"-s"（"--slient"）或是"--no-print-directory"，那么，"-w"总是失效的。
---++++4.5 定义命令包
如果Makefile中出现一些相同命令序列，那么我们可以为这些相同的命令序列定义一个变量。定义这种命令序列的语法以"define"开始，以"endef"结束，如：
define run-yacc
yacc $(firstword $^)
mv y.tab.c $@
endef
这里，"run-yacc"是这个命令包的名字，其不要和Makefile中的变量重名。在"define"和"endef"中的两行就是命令序列。这个命令包中的第一个命令是运行Yacc程序，因为Yacc程序总是生成"y.tab.c"的文件，所以第二行的命令就是把这个文件改改名字。还是把这个命令包放到一个示例中来看看吧。
foo.c : foo.y
$(run-yacc)
我们可以看见，要使用这个命令包，我们就好像使用变量一样。在这个命令包的使用中，命令包"run-yacc"中的"$^"就是"foo.y"，"$@" 就是"foo.c"（有关这种以"$"开头的特殊变量，我们会在后面介绍），make在执行命令包时，命令包中的每个命令会被依次独立执行。
0 Makefile概述
--------------------------------------------------------------------------------
什么是makefile？或许很多Winodws的程序员都不知道这个东西，因为那些Windows的IDE都为你做了这个工作，但我觉得要作一个好的和 professional的程序员，makefile还是要懂。这就好像现在有这么多的HTML的编辑器，但如果你想成为一个专业人士，你还是要了解 HTML的标识的含义。特别在Unix下的软件编译，你就不能不自己写makefile了，会不会写makefile，从一个侧面说明了一个人是否具备完成大型工程的能力。
因为，makefile关系到了整个工程的编译规则。一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作，因为makefile就像一个Shell 脚本一样，其中也可以执行操作系统的命令。
makefile带来的好处就是――"自动化编译"，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。
现在讲述如何写makefile的文章比较少，这是我想写这篇文章的原因。当然，不同产商的make各不相同，也有不同的语法，但其本质都是在"文件依赖性"上做文章，这里，我仅对GNU的make进行讲述，我的环境是RedHat Linux 8.0，make的版本是3.80。必竟，这个make是应用最为广泛的，也是用得最多的。而且其还是最遵循于IEEE 1003.2-1992 标准的（POSIX.2）。
在这篇文档中，将以C/C++的源码作为我们基础，所以必然涉及一些关于C/C++的编译的知识，相关于这方面的内容，还请各位查看相关的编译器的文档。这里所默认的编译器是UNIX下的GCC和CC。
0.1 关于程序的编译和链接
在此，我想多说关于程序编译的一些规范和方法，一般来说，无论是C、C++、还是pas，首先要把源文件编译成中间代码文件，在Windows下也就是 .obj 文件，UNIX下是 .o 文件，即 Object File，这个动作叫做编译（compile）。然后再把大量的Object File合成执行文件，这个动作叫作链接（link）。
编译时，编译器需要的是语法的正确，函数与变量的声明的正确。对于后者，通常是你需要告诉编译器头文件的所在位置（头文件中应该只是声明，而定义应该放在 C/C++文件中），只要所有的语法正确，编译器就可以编译出中间目标文件。一般来说，每个源文件都应该对应于一个中间目标文件（O文件或是OBJ文件）。
链接时，主要是链接函数和全局变量，所以，我们可以使用这些中间目标文件（O文件或是OBJ文件）来链接我们的应用程序。链接器并不管函数所在的源文件，只管函数的中间目标文件（Object File），在大多数时候，由于源文件太多，编译生成的中间目标文件太多，而在链接时需要明显地指出中间目标文件名，这对于编译很不方便，所以，我们要给中间目标文件打个包，在Windows下这种包叫"库文件"（Library File)，也就是 .lib 文件，在UNIX下，是Archive File，也就是 .a 文件。
总结一下，源文件首先会生成中间目标文件，再由中间目标文件生成执行文件。在编译时，编译器只检测程序语法，和函数、变量是否被声明。如果函数未被声明，编译器会给出一个警告，但可以生成Object File。而在链接程序时，链接器会在所有的Object File中找寻函数的实现，如果找不到，那到就会报链接错误码（Linker Error），在VC下，这种错误一般是：Link 2001错误，意思说是说，链接器未能找到函数的实现。你需要指定函数的Object File.
好，言归正传，GNU的make有许多的内容，闲言少叙，还是让我们开始吧。
1 Makefile 介绍
--------------------------------------------------------------------------------
make命令执行时，需要一个 Makefile 文件，以告诉make命令需要怎么样的去编译和链接程序。
首先，我们用一个示例来说明Makefile的书写规则。以便给大家一个感兴认识。这个示例来源于GNU的make使用手册，在这个示例中，我们的工程有 8个C文件，和3个头文件，我们要写一个Makefile来告诉make命令如何编译和链接这几个文件。我们的规则是：
如果这个工程没有编译过，那么我们的所有C文件都要编译并被链接。
如果这个工程的某几个C文件被修改，那么我们只编译被修改的C文件，并链接目标程序。
如果这个工程的头文件被改变了，那么我们需要编译引用了这几个头文件的C文件，并链接目标程序。
只要我们的Makefile写得够好，所有的这一切，我们只用一个make命令就可以完成，make命令会自动智能地根据当前的文件修改的情况来确定哪些文件需要重编译，从而自己编译所需要的文件和链接目标程序。
1.1 Makefile的规则
在讲述这个Makefile之前，还是让我们先来粗略地看一看Makefile的规则。
target ... : prerequisites ...
command
...
...
target也就是一个目标文件，可以是Object File，也可以是执行文件。还可以是一个标签（Label），对于标签这种特性，在后续的"伪目标"章节中会有叙述。
prerequisites就是，要生成那个target所需要的文件或是目标。
command也就是make需要执行的命令。（任意的Shell命令）
这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说，prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。这就是 Makefile的规则。也就是Makefile中最核心的内容。
说到底，Makefile的东西就是这样一点，好像我的这篇文档也该结束了。呵呵。还不尽然，这是Makefile的主线和核心，但要写好一个Makefile还不够，我会以后面一点一点地结合我的工作经验给你慢慢到来。内容还多着呢。：）
1.2 一个示例
正如前面所说的，如果一个工程有3个头文件，和8个C文件，我们为了完成前面所述的那三个规则，我们的Makefile应该是下面的这个样子的。
edit : main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
cc -o edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean :
rm edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
反斜杠（\）是换行符的意思。这样比较便于Makefile的易读。我们可以把这个内容保存在文件为"Makefile"或"makefile"的文件中，然后在该目录下直接输入命令"make"就可以生成执行文件edit。如果要删除执行文件和所有的中间目标文件，那么，只要简单地执行一下"make clean"就可以了。
在这个makefile中，目标文件（target）包含：执行文件edit和中间目标文件（*.o），依赖文件（prerequisites）就是冒号后面的那些 .c 文件和 .h文件。每一个 .o 文件都有一组依赖文件，而这些 .o 文件又是执行文件 edit 的依赖文件。依赖关系的实质上就是说明了目标文件是由哪些文件生成的，换言之，目标文件是哪些文件更新的。
在定义好依赖关系后，后续的那一行定义了如何生成目标文件的操作系统命令，一定要以一个Tab键作为开头。记住，make并不管命令是怎么工作的，他只管执行所定义的命令。make会比较targets文件和prerequisites文件的修改日期，如果prerequisites文件的日期要比 targets文件的日期要新，或者target不存在的话，那么，make就会执行后续定义的命令。
这里要说明一点的是，clean不是一个文件，它只不过是一个动作名字，有点像C语言中的lable一样，其冒号后什么也没有，那么，make就不会自动去找文件的依赖性，也就不会自动执行其后所定义的命令。要执行其后的命令，就要在make命令后明显得指出这个lable的名字。这样的方法非常有用，我们可以在一个makefile中定义不用的编译或是和编译无关的命令，比如程序的打包，程序的备份，等等。
1.3 make是如何工作的
在默认的方式下，也就是我们只输入make命令。那么，
make会在当前目录下找名字叫"Makefile"或"makefile"的文件。
如果找到，它会找文件中的第一个目标文件（target），在上面的例子中，他会找到"edit"这个文件，并把这个文件作为最终的目标文件。
如果edit文件不存在，或是edit所依赖的后面的 .o 文件的文件修改时间要比edit这个文件新，那么，他就会执行后面所定义的命令来生成edit这个文件。
如果edit所依赖的.o文件也存在，那么make会在当前文件中找目标为.o文件的依赖性，如果找到则再根据那一个规则生成.o文件。（这有点像一个堆栈的过程）
当然，你的C文件和H文件是存在的啦，于是make会生成 .o 文件，然后再用 .o 文件生命make的终极任务，也就是执行文件edit了。
这就是整个make的依赖性，make会一层又一层地去找文件的依赖关系，直到最终编译出第一个目标文件。在找寻的过程中，如果出现错误，比如最后被依赖的文件找不到，那么make就会直接退出，并报错，而对于所定义的命令的错误，或是编译不成功，make根本不理。make只管文件的依赖性，即，如果在我找了依赖关系之后，冒号后面的文件还是不在，那么对不起，我就不工作啦。
通过上述分析，我们知道，像clean这种，没有被第一个目标文件直接或间接关联，那么它后面所定义的命令将不会被自动执行，不过，我们可以显示要make执行。即命令――"make clean"，以此来清除所有的目标文件，以便重编译。
于是在我们编程中，如果这个工程已被编译过了，当我们修改了其中一个源文件，比如file.c，那么根据我们的依赖性，我们的目标file.o会被重编译（也就是在这个依性关系后面所定义的命令），于是file.o的文件也是最新的啦，于是file.o的文件修改时间要比edit要新，所以edit也会被重新链接了（详见edit目标文件后定义的命令）。
而如果我们改变了"command.h"，那么，kdb.o、command.o和files.o都会被重编译，并且，edit会被重链接。
1.4 makefile中使用变量
在上面的例子中，先让我们看看edit的规则：
edit : main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
cc -o edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
我们可以看到[.o]文件的字符串被重复了两次，如果我们的工程需要加入一个新的[.o]文件，那么我们需要在两个地方加（应该是三个地方，还有一个地方在clean中）。当然，我们的makefile并不复杂，所以在两个地方加也不累，但如果makefile变得复杂，那么我们就有可能会忘掉一个需要加入的地方，而导致编译失败。所以，为了makefile的易维护，在makefile中我们可以使用变量。makefile的变量也就是一个字符串，理解成C语言中的宏可能会更好。
比如，我们声明一个变量，叫objects, OBJECTS, objs, OBJS, obj, 或是 OBJ，反正不管什么啦，只要能够表示obj文件就行了。我们在makefile一开始就这样定义：
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
于是，我们就可以很方便地在我们的makefile中以"$(objects)"的方式来使用这个变量了，于是我们的改良版makefile就变成下面这个样子：
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean :
rm edit $(objects)
于是如果有新的 .o 文件加入，我们只需简单地修改一下 objects 变量就可以了。
关于变量更多的话题，我会在后续给你一一道来。
1.5 让make自动推导
GNU的make很强大，它可以自动推导文件以及文件依赖关系后面的命令，于是我们就没必要去在每一个[.o]文件后都写上类似的命令，因为，我们的make会自动识别，并自己推导命令。
只要make看到一个[.o]文件，它就会自动的把[.c]文件加在依赖关系中，如果make找到一个whatever.o，那么whatever.c，就会是whatever.o的依赖文件。并且 cc -c whatever.c 也会被推导出来，于是，我们的makefile再也不用写得这么复杂。我们的是新的makefile又出炉了。
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : defs.h
kbd.o : defs.h command.h
command.o : defs.h command.h
display.o : defs.h buffer.h
insert.o : defs.h buffer.h
search.o : defs.h buffer.h
files.o : defs.h buffer.h command.h
utils.o : defs.h
.PHONY : clean
clean :
rm edit $(objects)
这种方法，也就是make的"隐晦规则"。上面文件内容中，".PHONY"表示，clean是个伪目标文件。
关于更为详细的"隐晦规则"和"伪目标文件"，我会在后续给你一一道来。
1.6 另类风格的makefile
即然我们的make可以自动推导命令，那么我看到那堆[.o]和[.h]的依赖就有点不爽，那么多的重复的[.h]，能不能把其收拢起来，好吧，没有问题，这个对于make来说很容易，谁叫它提供了自动推导命令和文件的功能呢？来看看最新风格的makefile吧。
objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
$(objects) : defs.h
kbd.o command.o files.o : command.h
display.o insert.o search.o files.o : buffer.h
.PHONY : clean
clean :
rm edit $(objects)
这种风格，让我们的makefile变得很简单，但我们的文件依赖关系就显得有点凌乱了。鱼和熊掌不可兼得。还看你的喜好了。我是不喜欢这种风格的，一是文件的依赖关系看不清楚，二是如果文件一多，要加入几个新的.o文件，那就理不清楚了。
1.7 清空目标文件的规则
每个Makefile中都应该写一个清空目标文件（.o和执行文件）的规则，这不仅便于重编译，也很利于保持文件的清洁。这是一个"修养"（呵呵，还记得我的《编程修养》吗）。一般的风格都是：
clean:
rm edit $(objects)
更为稳健的做法是：
.PHONY : clean
clean :
-rm edit $(objects)
前面说过，.PHONY意思表示clean是一个"伪目标"，。而在rm命令前面加了一个小减号的意思就是，也许某些文件出现问题，但不要管，继续做后面的事。当然，clean的规则不要放在文件的开头，不然，这就会变成make的默认目标，相信谁也不愿意这样。不成文的规矩是――"clean从来都是放在文件的最后"。
上面就是一个makefile的概貌，也是makefile的基础，下面还有很多makefile的相关细节，准备好了吗？准备好了就来。
2 Makefile 总述
2.1 Makefile里有什么？
Makefile里主要包含了五个东西：显式规则、隐晦规则、变量定义、文件指示和注释。
显式规则。显式规则说明了，如何生成一个或多的的目标文件。这是由Makefile的书写者明显指出，要生成的文件，文件的依赖文件，生成的命令。
隐晦规则。由于我们的make有自动推导的功能，所以隐晦的规则可以让我们比较粗糙地简略地书写Makefile，这是由make所支持的。
变量的定义。在Makefile中我们要定义一系列的变量，变量一般都是字符串，这个有点你C语言中的宏，当Makefile被执行时，其中的变量都会被扩展到相应的引用位置上。
文件指示。其包括了三个部分，一个是在一个Makefile中引用另一个Makefile，就像C语言中的include一样；另一个是指根据某些情况指定Makefile中的有效部分，就像C语言中的预编译#if一样；还有就是定义一个多行的命令。有关这一部分的内容，我会在后续的部分中讲述。
注释。Makefile中只有行注释，和UNIX的Shell脚本一样，其注释是用"#"字符，这个就像C/C++中的"//"一样。如果你要在你的Makefile中使用"#"字符，可以用反斜框进行转义，如："\#"。
最后，还值得一提的是，在Makefile中的命令，必须要以[Tab]键开始。
2.2Makefile的文件名
默认的情况下，make命令会在当前目录下按顺序找寻文件名为"GNUmakefile"、"makefile"、"Makefile"的文件，找到了解释这个文件。在这三个文件名中，最好使用"Makefile"这个文件名，因为，这个文件名第一个字符为大写，这样有一种显目的感觉。最好不要用 "GNUmakefile"，这个文件是GNU的make识别的。有另外一些make只对全小写的"makefile"文件名敏感，但是基本上来说，大多数的make都支持"makefile"和"Makefile"这两种默认文件名。
当然，你可以使用别的文件名来书写Makefile，比如："Make.Linux"，"Make.Solaris"，"Make.AIX"等，如果要指定特定的Makefile，你可以使用make的"-f"和"--file"参数，如：make -f Make.Linux或make --file Make.AIX。
2.3 引用其它的Makefile
在Makefile使用include关键字可以把别的Makefile包含进来，这很像C语言的#include，被包含的文件会原模原样的放在当前文件的包含位置。include的语法是：
include <filename>filename可以是当前操作系统Shell的文件模式（可以保含路径和通配符）
在include前面可以有一些空字符，但是绝不能是[Tab]键开始。include和可以用一个或多个空格隔开。举个例子，你有这样几个 Makefile：a.mk、b.mk、c.mk，还有一个文件叫foo.make，以及一个变量$(bar)，其包含了e.mk和f.mk，那么，下面的语句：
include foo.make *.mk $(bar)
等价于：
include foo.make a.mk b.mk c.mk e.mk f.mk
make命令开始时，会把找寻include所指出的其它Makefile，并把其内容安置在当前的位置。就好像C/C++的#include指令一样。如果文件都没有指定绝对路径或是相对路径的话，make会在当前目录下首先寻找，如果当前目录下没有找到，那么，make还会在下面的几个目录下找：
如果make执行时，有"-I"或"--include-dir"参数，那么make就会在这个参数所指定的目录下去寻找。
如果目录/include（一般是：/usr/local/bin或/usr/include）存在的话，make也会去找。
如果有文件没有找到的话，make会生成一条警告信息，但不会马上出现致命错误。它会继续载入其它的文件，一旦完成makefile的读取，make会再重试这些没有找到，或是不能读取的文件，如果还是不行，make才会出现一条致命信息。如果你想让make不理那些无法读取的文件，而继续执行，你可以在 include前加一个减号"-"。如：
-include <filename>其表示，无论include过程中出现什么错误，都不要报错继续执行。和其它版本make兼容的相关命令是sinclude，其作用和这一个是一样的。
2.4 环境变量 MAKEFILES
如果你的当前环境中定义了环境变量MAKEFILES，那么，make会把这个变量中的值做一个类似于include的动作。这个变量中的值是其它的 Makefile，用空格分隔。只是，它和include不同的是，从这个环境变中引入的Makefile的"目标"不会起作用，如果环境变量中定义的文件发现错误，make也会不理。
但是在这里我还是建议不要使用这个环境变量，因为只要这个变量一被定义，那么当你使用make时，所有的Makefile都会受到它的影响，这绝不是你想看到的。在这里提这个事，只是为了告诉大家，也许有时候你的Makefile出现了怪事，那么你可以看看当前环境中有没有定义这个变量。
2.5 make的工作方式
GNU的make工作时的执行步骤入下：（想来其它的make也是类似）
读入所有的Makefile。
读入被include的其它Makefile。
初始化文件中的变量。
推导隐晦规则，并分析所有规则。
为所有的目标文件创建依赖关系链。
根据依赖关系，决定哪些目标要重新生成。
执行生成命令。
1-5步为第一个阶段，6-7为第二个阶段。第一个阶段中，如果定义的变量被使用了，那么，make会把其展开在使用的位置。但make并不会完全马上展开，make使用的是拖延战术，如果变量出现在依赖关系的规则中，那么仅当这条依赖被决定要使用了，变量才会在其内部展开。
当然，这个工作方式你不一定要清楚，但是知道这个方式你也会对make更为熟悉。有了这个基础，后续部分也就容易看懂了。
3 Makefile书写规则
--------------------------------------------------------------------------------
规则包含两个部分，一个是依赖关系，一个是生成目标的方法。
在Makefile中，规则的顺序是很重要的，因为，Makefile中只应该有一个最终目标，其它的目标都是被这个目标所连带出来的，所以一定要让 make知道你的最终目标是什么。一般来说，定义在Makefile中的目标可能会有很多，但是第一条规则中的目标将被确立为最终的目标。如果第一条规则中的目标有很多个，那么，第一个目标会成为最终的目标。make所完成的也就是这个目标。
好了，还是让我们来看一看如何书写规则。
3.1 规则举例
foo.o : foo.c defs.h # foo模块
cc -c -g foo.c
看到这个例子，各位应该不是很陌生了，前面也已说过，foo.o是我们的目标，foo.c和defs.h是目标所依赖的源文件，而只有一个命令"cc -c -g foo.c"（以Tab键开头）。这个规则告诉我们两件事：
文件的依赖关系，foo.o依赖于foo.c和defs.h的文件，如果foo.c和defs.h的文件日期要比foo.o文件日期要新，或是foo.o不存在，那么依赖关系发生。
如果生成（或更新）foo.o文件。也就是那个cc命令，其说明了，如何生成foo.o这个文件。（当然foo.c文件include了defs.h文件）
3.2 规则的语法
targets : prerequisites
command
...
或是这样：
targets : prerequisites ; command
command
...
targets是文件名，以空格分开，可以使用通配符。一般来说，我们的目标基本上是一个文件，但也有可能是多个文件。
command是命令行，如果其不与"target:prerequisites"在一行，那么，必须以[Tab键]开头，如果和prerequisites在一行，那么可以用分号做为分隔。（见上）
prerequisites也就是目标所依赖的文件（或依赖目标）。如果其中的某个文件要比目标文件要新，那么，目标就被认为是"过时的"，被认为是需要重生成的。这个在前面已经讲过了。
如果命令太长，你可以使用反斜框（'\'）作为换行符。make对一行上有多少个字符没有限制。规则告诉make两件事，文件的依赖关系和如何成成目标文件。
一般来说，make会以UNIX的标准Shell，也就是/bin/sh来执行命令。
3.3 在规则中使用通配符
如果我们想定义一系列比较类似的文件，我们很自然地就想起使用通配符。make支持三各通配符："*"，"?"和"[...]"。这是和Unix的B-Shell是相同的。
波浪号（"~"）字符在文件名中也有比较特殊的用途。如果是"~/test"，这就表示当前用户的$HOME目录下的test目录。而"~hchen /test"则表示用户hchen的宿主目录下的test目录。（这些都是Unix下的小知识了，make也支持）而在Windows或是MS-DOS 下，用户没有宿主目录，那么波浪号所指的目录则根据环境变量"HOME"而定。
通配符代替了你一系列的文件，如"*.c"表示所以后缀为c的文件。一个需要我们注意的是，如果我们的文件名中有通配符，如："*"，那么可以用转义字符"\"，如"\*"来表示真实的"*"字符，而不是任意长度的字符串。
好吧，还是先来看几个例子吧：
clean:
rm -f *.o
上面这个例子我不不多说了，这是操作系统Shell所支持的通配符。这是在命令中的通配符。
print: *.c
lpr -p $?
touch print
上面这个例子说明了通配符也可以在我们的规则中，目标print依赖于所有的[.c]文件。其中的"$?"是一个自动化变量，我会在后面给你讲述。
objects = *.o
上面这个例子，表示了，通符同样可以用在变量中。并不是说[*.o]会展开，不！objects的值就是"*.o"。Makefile中的变量其实就是 C/C++中的宏。如果你要让通配符在变量中展开，也就是让objects的值是所有[.o]的文件名的集合，那么，你可以这样：
objects := $(wildcard *.o)
这种用法由关键字"wildcard"指出，关于Makefile的关键字，我们将在后面讨论。
3.4 文件搜寻
在一些大的工程中，有大量的源文件，我们通常的做法是把这许多的源文件分类，并存放在不同的目录中。所以，当make需要去找寻文件的依赖关系时，你可以在文件前加上路径，但最好的方法是把一个路径告诉make，让make在自动去找。
Makefile文件中的特殊变量"VPATH"就是完成这个功能的，如果没有指明这个变量，make只会在当前的目录中去找寻依赖文件和目标文件。如果定义了这个变量，那么，make就会在当当前目录找不到的情况下，到所指定的目录中去找寻文件了。
VPATH = src:../headers
上面的的定义指定两个目录，"src"和"../headers"，make会按照这个顺序进行搜索。目录由"冒号"分隔。（当然，当前目录永远是最高优先搜索的地方）
另一个设置文件搜索路径的方法是使用make的"vpath"关键字（注意，它是全小写的），这不是变量，这是一个make的关键字，这和上面提到的那个 VPATH变量很类似，但是它更为灵活。它可以指定不同的文件在不同的搜索目录中。这是一个很灵活的功能。它的使用方法有三种：
vpath < pattern> < directories>
为符合模式 < pattern>的文件指定搜索目录 < directories>。
vpath < pattern>
清除符合模式 < pattern>的文件的搜索目录。
vpath
清除所有已被设置好了的文件搜索目录。
vapth使用方法中的 < pattern>需要包含"%"字符。"%"的意思是匹配零或若干字符，例如，"%.h"表示所有以".h"结尾的文件。 < pattern>指定了要搜索的文件集，而 < directories>则指定了的文件集的搜索的目录。例如：
vpath %.h ../headers
该语句表示，要求make在"../headers"目录下搜索所有以".h"结尾的文件。（如果某文件在当前目录没有找到的话）
我们可以连续地使用vpath语句，以指定不同搜索策略。如果连续的vpath语句中出现了相同的 < pattern>，或是被重复了的 < pattern>，那么，make会按照vpath语句的先后顺序来执行搜索。如：
vpath %.c foo
vpath % blish
vpath %.c bar
其表示".c"结尾的文件，先在"foo"目录，然后是"blish"，最后是"bar"目录。
vpath %.c foo:bar
vpath % blish
而上面的语句则表示".c"结尾的文件，先在"foo"目录，然后是"bar"目录，最后才是"blish"目录。
3.5 伪目标
最早先的一个例子中，我们提到过一个"clean"的目标，这是一个"伪目标"，
clean:
rm *.o temp
正像我们前面例子中的"clean"一样，即然我们生成了许多文件编译文件，我们也应该提供一个清除它们的"目标"以备完整地重编译而用。 （以"make clean"来使用该目标）
因为，我们并不生成"clean"这个文件。"伪目标"并不是一个文件，只是一个标签，由于"伪目标"不是文件，所以make无法生成它的依赖关系和决定它是否要执行。我们只有通过显示地指明这个"目标"才能让其生效。当然，"伪目标"的取名不能和文件名重名，不然其就失去了"伪目标"的意义了。
当然，为了避免和文件重名的这种情况，我们可以使用一个特殊的标记".PHONY"来显示地指明一个目标是"伪目标"，向make说明，不管是否有这个文件，这个目标就是"伪目标"。
.PHONY : clean
只要有这个声明，不管是否有"clean"文件，要运行"clean"这个目标，只有"make clean"这样。于是整个过程可以这样写：
.PHONY: clean
clean:
rm *.o temp
伪目标一般没有依赖的文件。但是，我们也可以为伪目标指定所依赖的文件。伪目标同样可以作为"默认目标"，只要将其放在第一个。一个示例就是，如果你的 Makefile需要一口气生成若干个可执行文件，但你只想简单地敲一个make完事，并且，所有的目标文件都写在一个Makefile中，那么你可以使用"伪目标"这个特性：
all : prog1 prog2 prog3
.PHONY : all
prog1 : prog1.o utils.o
cc -o prog1 prog1.o utils.o
prog2 : prog2.o
cc -o prog2 prog2.o
prog3 : prog3.o sort.o utils.o
cc -o prog3 prog3.o sort.o utils.o
我们知道，Makefile中的第一个目标会被作为其默认目标。我们声明了一个"all"的伪目标，其依赖于其它三个目标。由于伪目标的特性是，总是被执行的，所以其依赖的那三个目标就总是不如"all"这个目标新。所以，其它三个目标的规则总是会被决议。也就达到了我们一口气生成多个目标的目的。 ".PHONY : all"声明了"all"这个目标为"伪目标"。
随便提一句，从上面的例子我们可以看出，目标也可以成为依赖。所以，伪目标同样也可成为依赖。看下面的例子：
.PHONY: cleanall cleanobj cleandiff
cleanall : cleanobj cleandiff
rm program
cleanobj :
rm *.o
cleandiff :
rm *.diff
"make clean"将清除所有要被清除的文件。"cleanobj"和"cleandiff"这两个伪目标有点像"子程序"的意思。我们可以输入"make cleanall"和"make cleanobj"和"make cleandiff"命令来达到清除不同种类文件的目的
3.6 多目标
Makefile的规则中的目标可以不止一个，其支持多目标，有可能我们的多个目标同时依赖于一个文件，并且其生成的命令大体类似。于是我们就能把其合并起来。当然，多个目标的生成规则的执行命令是同一个，这可能会可我们带来麻烦，不过好在我们的可以使用一个自动化变量"$@"（关于自动化变量，将在后面讲述），这个变量表示着目前规则中所有的目标的集合，这样说可能很抽象，还是看一个例子吧。
bigoutput littleoutput : text.g
generate text.g -$(subst output,,$@) > $@
上述规则等价于：
bigoutput : text.g
generate text.g -big > bigoutput
littleoutput : text.g
generate text.g -little > littleoutput
其中，-$(subst output,,$@)中的"$"表示执行一个Makefile的函数，函数名为subst，后面的为参数。关于函数，将在后面讲述。这里的这个函数是截取字符串的意思，"$@"表示目标的集合，就像一个数组，"$@"依次取出目标，并执于命令。
3.7 静态模式
静态模式可以更加容易地定义多目标的规则，可以让我们的规则变得更加的有弹性和灵活。我们还是先来看一下语法：
<targets ...>: <target-pattern>: <prereq-patterns ...>
<commands>
...targets定义了一系列的目标文件，可以有通配符。是目标的一个集合。
target-parrtern是指明了targets的模式，也就是的目标集模式。
prereq-parrterns是目标的依赖模式，它对target-parrtern形成的模式再进行一次依赖目标的定义。
这样描述这三个东西，可能还是没有说清楚，还是举个例子来说明一下吧。如果我们的 <target-parrtern>定义成"%.o"，意思是我们的集合中都是以".o"结尾的，而如果我们的 <prereq-parrterns>定义成"%.c"，意思是对 <target-parrtern>所形成的目标集进行二次定义，其计算方法是，取 <target-parrtern>模式中的"%"（也就是去掉了[.o]这个结尾），并为其加上[.c]这个结尾，形成的新集合。
所以，我们的"目标模式"或是"依赖模式"中都应该有"%"这个字符，如果你的文件名中有"%"那么你可以使用反斜杠"\"进行转义，来标明真实的"%"字符。
看一个例子：
objects = foo.o bar.o
all: $(objects)
$(objects): %.o: %.c
$(CC) -c $(CFLAGS) $ < -o $@
上面的例子中，指明了我们的目标从$object中获取，"%.o"表明要所有以".o"结尾的目标，也就是"foo.o bar.o"，也就是变量$object集合的模式，而依赖模式"%.c"则取模式"%.o"的"%"，也就是"foo bar"，并为其加下".c"的后缀，于是，我们的依赖目标就是"foo.c bar.c"。而命令中的"$ <"和"$@"则是自动化变量，"$ <"表示所有的依赖目标集（也就是"foo.c bar.c"），"$@"表示目标集（也褪恰�oo.o bar.o"）。于是，上面的规则展开后等价于下面的规则：
foo.o : foo.c
$(CC) -c $(CFLAGS) foo.c -o foo.o
bar.o : bar.c
$(CC) -c $(CFLAGS) bar.c -o bar.o
试想，如果我们的"%.o"有几百个，那种我们只要用这种很简单的"静态模式规则"就可以写完一堆规则，实在是太有效率了。"静态模式规则"的用法很灵活，如果用得好，那会一个很强大的功能。再看一个例子：
files = foo.elc bar.o lose.o
$(filter %.o,$(files)): %.o: %.c
$(CC) -c $(CFLAGS) $ < -o $@
$(filter %.elc,$(files)): %.elc: %.el
emacs -f batch-byte-compile $ <
$(filter %.o,$(files))表示调用Makefile的filter函数，过滤"$filter"集，只要其中模式为"%.o"的内容。其的它内容，我就不用多说了吧。这个例字展示了Makefile中更大的弹性。
3.8 自动生成依赖性
在Makefile中，我们的依赖关系可能会需要包含一系列的头文件，比如，如果我们的main.c中有一句"#include "defs.h""，那么我们的依赖关系应该是：
main.o : main.c defs.h
但是，如果是一个比较大型的工程，你必需清楚哪些C文件包含了哪些头文件，并且，你在加入或删除头文件时，也需要小心地修改Makefile，这是一个很没有维护性的工作。为了避免这种繁重而又容易出错的事情，我们可以使用C/C++编译的一个功能。大多数的C/C++编译器都支持一个"-M"的选项，即自动找寻源文件中包含的头文件，并生成一个依赖关系。例如，如果我们执行下面的命令：
cc -M main.c
其输出是：
main.o : main.c defs.h
于是由编译器自动生成的依赖关系，这样一来，你就不必再手动书写若干文件的依赖关系，而由编译器自动生成了。需要提醒一句的是，如果你使用GNU的C/C++编译器，你得用"-MM"参数，不然，"-M"参数会把一些标准库的头文件也包含进来。
gcc -M main.c的输出是：
main.o: main.c defs.h /usr/include/stdio.h /usr/include/features.h \
/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \
/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/stddef.h \
/usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
/usr/include/bits/sched.h /usr/include/libio.h \
/usr/include/_G_config.h /usr/include/wchar.h \
/usr/include/bits/wchar.h /usr/include/gconv.h \
/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/stdarg.h \
/usr/include/bits/stdio_lim.h
gcc -MM main.c的输出则是：
main.o: main.c defs.h
那么，编译器的这个功能如何与我们的Makefile联系在一起呢。因为这样一来，我们的Makefile也要根据这些源文件重新生成，让 Makefile自已依赖于源文件？这个功能并不现实，不过我们可以有其它手段来迂回地实现这一功能。GNU组织建议把编译器为每一个源文件的自动生成的依赖关系放到一个文件中，为每一个"name.c"的文件都生成一个"name.d"的Makefile文件，[.d]文件中就存放对应[.c]文件的依赖关系。
于是，我们可以写出[.c]文件和[.d]文件的依赖关系，并让make自动更新或自成[.d]文件，并把其包含在我们的主Makefile中，这样，我们就可以自动化地生成每个文件的依赖关系了。
这里，我们给出了一个模式规则来产生[.d]文件：
%.d: %.c
@set -e; rm -f $@; \
$(CC) -M $(CPPFLAGS) $ < > $@.$$$$; \
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$
这个规则的意思是，所有的[.d]文件依赖于[.c]文件，"rm -f $@"的意思是删除所有的目标，也就是[.d]文件，第二行的意思是，为每个依赖文件"$ <"，也就是[.c]文件生成依赖文件，"$@"表示模式"%.d"文件，如果有一个C文件是name.c，那么"%"就是 "name"，"$$$$"意为一个随机编号，第二行生成的文件有可能是"name.d.12345"，第三行使用sed命令做了一个替换，关于sed命令的用法请参看相关的使用文档。第四行就是删除临时文件。
总而言之，这个模式要做的事就是在编译器生成的依赖关系中加入[.d]文件的依赖，即把依赖关系：
main.o : main.c defs.h
转成：
main.o main.d : main.c defs.h
于是，我们的[.d]文件也会自动更新了，并会自动生成了，当然，你还可以在这个[.d]文件中加入的不只是依赖关系，包括生成的命令也可一并加入，让每个[.d]文件都包含一个完赖的规则。一旦我们完成这个工作，接下来，我们就要把这些自动生成的规则放进我们的主Makefile中。我们可以使用 Makefile的"include"命令，来引入别的Makefile文件（前面讲过），例如：
sources = foo.c bar.c
include $(sources:.c=.d)
上述语句中的"$(sources:.c=.d)"中的".c=.d"的意思是做一个替换，把变量$(sources)所有[.c]的字串都替换成 [.d]，关于这个"替换"的内容，在后面我会有更为详细的讲述。当然，你得注意次序，因为include是按次来载入文件，最先载入的[.d]文件中的目标会成为默认目标.
4 Makefile 书写命令
--------------------------------------------------------------------------------
每条规则中的命令和操作系统Shell的命令行是一致的。make会一按顺序一条一条的执行命令，每条命令的开头必须以[Tab]键开头，除非，命令是紧跟在依赖规则后面的分号后的。在命令行之间中的空格或是空行会被忽略，但是如果该空格或空行是以Tab键开头的，那么make会认为其是一个空命令。
我们在UNIX下可能会使用不同的Shell，但是make的命令默认是被"/bin/sh"――UNIX的标准Shell解释执行的。除非你特别指定一个其它的Shell。Makefile中，"#"是注释符，很像C/C++中的"//"，其后的本行字符都被注释。
4.1 显示命令
通常，make会把其要执行的命令行在命令执行前输出到屏幕上。当我们用"@"字符在命令行前，那么，这个命令将不被make显示出来，最具代表性的例子是，我们用这个功能来像屏幕显示一些信息。如：
@echo 正在编译XXX模块......
当make执行时，会输出"正在编译XXX模块......"字串，但不会输出命令，如果没有"@"，那么，make将输出：
echo 正在编译XXX模块......
正在编译XXX模块......
如果make执行时，带入make参数"-n"或"--just-print"，那么其只是显示命令，但不会执行命令，这个功能很有利于我们调试我们的Makefile，看看我们书写的命令是执行起来是什么样子的或是什么顺序的。
而make参数"-s"或"--slient"则是全面禁止命令的显示。
4.2 命令执行
当依赖目标新于目标时，也就是当规则的目标需要被更新时，make会一条一条的执行其后的命令。需要注意的是，如果你要让上一条命令的结果应用在下一条命令时，你应该使用分号分隔这两条命令。比如你的第一条命令是cd命令，你希望第二条命令得在cd之后的基础上运行，那么你就不能把这两条命令写在两行上，而应该把这两条命令写在一行上，用分号分隔。如：
示例一：
exec:
cd /home/hchen
pwd
示例二：
exec:
cd /home/hchen; pwd
当我们执行"make exec"时，第一个例子中的cd没有作用，pwd会打印出当前的Makefile目录，而第二个例子中，cd就起作用了，pwd会打印出"/home/hchen"。
make一般是使用环境变量SHELL中所定义的系统Shell来执行命令，默认情况下使用UNIX的标准Shell――/bin/sh来执行命令。但在 MS-DOS下有点特殊，因为MS-DOS下没有SHELL环境变量，当然你也可以指定。如果你指定了UNIX风格的目录形式，首先，make会在 SHELL所指定的路径中找寻命令解释器，如果找不到，其会在当前盘符中的当前目录中寻找，如果再找不到，其会在PATH环境变量中所定义的所有路径中寻找。MS-DOS中，如果你定义的命令解释器没有找到，其会给你的命令解释器加上诸如".exe"、".com"、".bat"、".sh"等后缀。
4.3 命令出错
每当命令运行完后，make会检测每个命令的返回码，如果命令返回成功，那么make会执行下一条命令，当规则中所有的命令成功返回后，这个规则就算是成功完成了。如果一个规则中的某个命令出错了（命令退出码非零），那么make就会终止执行当前规则，这将有可能终止所有规则的执行。
有些时候，命令的出错并不表示就是错误的。例如mkdir命令，我们一定需要建立一个目录，如果目录不存在，那么mkdir就成功执行，万事大吉，如果目录存在，那么就出错了。我们之所以使用mkdir的意思就是一定要有这样的一个目录，于是我们就不希望mkdir出错而终止规则的运行。
为了做到这一点，忽略命令的出错，我们可以在Makefile的命令行前加一个减号"-"（在Tab键之后），标记为不管命令出不出错都认为是成功的。如：
clean:
-rm -f *.o
还有一个全局的办法是，给make加上"-i"或是"--ignore-errors"参数，那么，Makefile中所有命令都会忽略错误。而如果一个规则是以".IGNORE"作为目标的，那么这个规则中的所有命令将会忽略错误。这些是不同级别的防止命令出错的方法，你可以根据你的不同喜欢设置。
还有一个要提一下的make的参数的是"-k"或是"--keep-going"，这个参数的意思是，如果某规则中的命令出错了，那么就终目该规则的执行，但继续执行其它规则。
4.4 嵌套执行make
在一些大的工程中，我们会把我们不同模块或是不同功能的源文件放在不同的目录中，我们可以在每个目录中都书写一个该目录的Makefile，这有利于让我们的Makefile变得更加地简洁，而不至于把所有的东西全部写在一个Makefile中，这样会很难维护我们的Makefile，这个技术对于我们模块编译和分段编译有着非常大的好处。
例如，我们有一个子目录叫subdir，这个目录下有个Makefile文件，来指明了这个目录下文件的编译规则。那么我们总控的Makefile可以这样书写：
subsystem:
cd subdir && $(MAKE)
其等价于：
subsystem:
$(MAKE) -C subdir
定义$(MAKE)宏变量的意思是，也许我们的make需要一些参数，所以定义成一个变量比较利于维护。这两个例子的意思都是先进入"subdir"目录，然后执行make命令。
我们把这个Makefile叫做"总控Makefile"，总控Makefile的变量可以传递到下级的Makefile中（如果你显示的声明），但是不会覆盖下层的Makefile中所定义的变量，除非指定了"-e"参数。
如果你要传递变量到下级Makefile中，那么你可以使用这样的声明：
export <variable ...>
如果你不想让某些变量传递到下级Makefile中，那么你可以这样声明：
unexport <variable ...>
如：
示例一：
export variable = value
其等价于：
variable = value
export variable
其等价于：
export variable := value
其等价于：
variable := value
export variable
示例二：
export variable += value
其等价于：
variable += value
export variable
如果你要传递所有的变量，那么，只要一个export就行了。后面什么也不用跟，表示传递所有的变量。
需要注意的是，有两个变量，一个是SHELL，一个是MAKEFLAGS，这两个变量不管你是否export，其总是要传递到下层Makefile中，特别是MAKEFILES变量，其中包含了make的参数信息，如果我们执行"总控Makefile"时有make参数或是在上层Makefile中定义了这个变量，那么MAKEFILES变量将会是这些参数，并会传递到下层Makefile中，这是一个系统级的环境变量。
但是make命令中的有几个参数并不往下传递，它们是"-C","-f","-h""-o"和"-W"（有关Makefile参数的细节将在后面说明），如果你不想往下层传递参数，那么，你可以这样来：
subsystem:
cd subdir && $(MAKE) MAKEFLAGS=
如果你定义了环境变量MAKEFLAGS，那么你得确信其中的选项是大家都会用到的，如果其中有"-t","-n",和"-q"参数，那么将会有让你意想不到的结果，或许会让你异常地恐慌。
还有一个在"嵌套执行"中比较有用的参数，"-w"或是"--print-directory"会在make的过程中输出一些信息，让你看到目前的工作目录。比如，如果我们的下级make目录是"/home/hchen/gnu/make"，如果我们使用"make -w"来执行，那么当进入该目录时，我们会看到：
make: Entering directory `/home/hchen/gnu/make'.
而在完成下层make后离开目录时，我们会看到：
make: Leaving directory `/home/hchen/gnu/make'
当你使用"-C"参数来指定make下层Makefile时，"-w"会被自动打开的。如果参数中有"-s"（"--slient"）或是"--no-print-directory"，那么，"-w"总是失效的。
---++++4.5 定义命令包
如果Makefile中出现一些相同命令序列，那么我们可以为这些相同的命令序列定义一个变量。定义这种命令序列的语法以"define"开始，以"endef"结束，如：
define run-yacc
yacc $(firstword $^)
mv y.tab.c $@
endef
这里，"run-yacc"是这个命令包的名字，其不要和Makefile中的变量重名。在"define"和"endef"中的两行就是命令序列。这个命令包中的第一个命令是运行Yacc程序，因为Yacc程序总是生成"y.tab.c"的文件，所以第二行的命令就是把这个文件改改名字。还是把这个命令包放到一个示例中来看看吧。
foo.c : foo.y
$(run-yacc)
我们可以看见，要使用这个命令包，我们就好像使用变量一样。在这个命令包的使用中，命令包"run-yacc"中的"$^"就是"foo.y"，"$@" 就是"foo.c"（有关这种以"$"开头的特殊变量，我们会在后面介绍），make在执行命令包时，命令包中的每个命令会被依次独立执行。
2009年3月23日星期一
Asio 网络库
搜索: Search Search Titles Search Full Text
更多操作 源码 打印视图 输出Docbook格式 删除缓存 ------------ 拼写检查 相似网页 本站地图 ------------ 改名 删除 ------------ 我的网页 订阅 ------------ 删除垃圾广告 网页打包 ------------ Visual Site Map
BOOST 绝对实用手册(写作中!!!!!!!)
目录
1. 序言
2. 编译:VC2005注意
3. Asio 网络库
1. 网络库:VC2005注意
2. 同步Timer
3. 异步Timer
4. 回调函数的参数
5. 成员函数作为回调函数
6. 多线程回调同步
7. TCP客户端:对准时间
8. TCP同步时间服务器
张沈鹏 电子科技大学大三 生物医学工程
- -- Any Question,Please Email To zsp007@gmail.com
更新:2006.10 beta
参考:BOOST文档
- -- 欢迎转载,但请保留引用网址以获得更新
1. 序言
现在学的东西很容易忘记,写这篇文章的目的是能让我在需要时快速找回当时的感觉. Let's BOOST THE WORLD .
2. 编译:VC2005注意
在 属性->C/C++->预处理器->预处理定义 中加入
_CRT_SECURE_NO_DEPRECATE;
来屏蔽不必要的警告
3. Asio 网络库
Boost.Asio是利用当代C++的先进方法,跨平台,异步I/O模型的C++网络库.
3.1. 网络库:VC2005注意
在 属性->C/C++->命令行 中加入
-DBOOST_REGEX_NO_LIB
来防止自动连接.
3.2. 同步Timer
本章介绍asio如何在定时器上进行阻塞等待(blocking wait).
实现,我们包含必要的头文件.
所有的asio类可以简单的通过include "asio.hpp"来调用.
#include <iostream>
#include <boost/asio.hpp>
#include <boost/asio.hpp>
此外,这个示例用到了timer,我们还要包含Boost.Date_Time的头文件来控制时间.
#include <boost/date_time/posix_time/posix_time.hpp>
使用asio至少需要一个boost::asio::io_service对象.该类提供了访问I/O的功能.我们首先在main函数中声明它.
int main()
{
boost::asio::io_service io;
{
boost::asio::io_service io;
下 一步我们声明boost::asio::deadline_timer对象.这个asio的核心类提供I/O的功能(这里更确切的说是定时功能),总是把 一个io_service对象作为他的第一个构造函数,而第二个构造函数的参数设定timer会在5秒后到时(expired).
boost::asio::deadline_timer t(io, boost::posix_time::seconds(5));
这个简单的示例中我们演示了定时器上的一个阻塞等待.就是说,调用boost::asio::deadline_timer::wait()的在创建后5秒内(注意:不是等待开始后),timer到时之前不会返回任何值.
一个deadline_timer只有两种状态:到时,未到时.
如果boost::asio::deadline_timer::wait()在到时的timer对象上调用,会立即return.
t.wait();
最后,我们输出理所当然的"Hello, world!"来演示timer到时了.
std::cout << "Hello, world!\n";
return 0;
}
return 0;
}
完整的代码:
#include <iostream>
#include <boost/asio.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
int main()
{
boost::asio::io_service io;
boost::asio::deadline_timer t(io, boost::posix_time::seconds(5));
t.wait();
std::cout << "Hello, world!\n";
return 0;
}
#include <boost/asio.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
int main()
{
boost::asio::io_service io;
boost::asio::deadline_timer t(io, boost::posix_time::seconds(5));
t.wait();
std::cout << "Hello, world!\n";
return 0;
}
3.3. 异步Timer
#include <iostream>
#include <asio.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
#include <asio.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
asio的异步函数会在一个异步操作完成后被回调.这里我们定义了一个将被回调的函数.
void print(const asio::error& /*e*/)
{
std::cout << "Hello, world!\n";
}
int main()
{
asio::io_service io;
asio::deadline_timer t(io, boost::posix_time::seconds(5));
{
std::cout << "Hello, world!\n";
}
int main()
{
asio::io_service io;
asio::deadline_timer t(io, boost::posix_time::seconds(5));
这里我们调用asio::deadline_timer::async_wait()来异步等待
t.async_wait(print);
最后,我们必须调用asio::io_service::run().
asio库只会调用那个正在运行的asio::io_service::run()的回调函数.
如果asio::io_service::run()不被调用,那么回调永远不会发生.
asio::io_service::run()会持续工作到点,这里就是timer到时,回调完成.
别 忘了在调用 asio::io_service::run()之前设置好io_service的任务.比如,这里,如果我们忘记先调用 asio::deadline_timer::async_wait()则asio::io_service::run()会在瞬间return.
io.run();
return 0;
}
return 0;
}
完整的代码:
#include <iostream>
#include <asio.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
void print(const asio::error& /*e*/)
{
std::cout << "Hello, world!\n";
}
int main()
{
asio::io_service io;
asio::deadline_timer t(io, boost::posix_time::seconds(5));
t.async_wait(print);
io.run();
return 0;
}
#include <asio.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
void print(const asio::error& /*e*/)
{
std::cout << "Hello, world!\n";
}
int main()
{
asio::io_service io;
asio::deadline_timer t(io, boost::posix_time::seconds(5));
t.async_wait(print);
io.run();
return 0;
}
3.4. 回调函数的参数
这里我们将每秒回调一次,来演示如何回调函数参数的含义
#include <iostream>
#include <asio.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
#include <asio.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
首先,调整一下timer的持续时间,开始一个异步等待.显示,回调函数需要访问timer来实现周期运行,所以我们再介绍两个新参数
- 指向timer的指针
- 一个int*来指向计数器
void print(const asio::error& /*e*/,
asio::deadline_timer* t, int* count)
{
asio::deadline_timer* t, int* count)
{
我 们打算让这个函数运行6个周期,然而你会发现这里没有显式的方法来终止io_service.不过,回顾上一节,你会发现当 asio::io_service::run()会在所有任务完成时终止.这样我们当计算器的值达到5时(0为第一次运行的值),不再开启一个新的异步等 待就可以了.
if (*count < 5)
{
std::cout << *count << "\n";
++(*count);
{
std::cout << *count << "\n";
++(*count);
然后,我们推迟的timer的终止时间.通过在原先的终止时间上增加延时,我们可以确保timer不会在处理回调函数所需时间内的到期.
(原 文:By calculating the new expiry time relative to the old, we can ensure that the timer does not drift away from the whole-second mark due to any delays in processing the handler.)
t->expires_at(t->expires_at() + boost::posix_time::seconds(1));
然后我们开始一个新的同步等待.如您所见,我们用把print和他的多个参数用boost::bind函数合成一个的形为void(const asio::error&)回调函数(准确的说是function object).
在 这个例子中, boost::bind的asio::placeholders::error参数是为了给回调函数传入一个error对象.当进行一个异步操作,开始 boost::bind时,你需要使用它来匹配回调函数的参数表.下一节中你会学到回调函数不需要error参数时可以省略它.
t->async_wait(boost::bind(print,
asio::placeholders::error, t, count));
}
}
int main()
{
asio::io_service io;
int count = 0;
asio::deadline_timer t(io, boost::posix_time::seconds(1));
asio::placeholders::error, t, count));
}
}
int main()
{
asio::io_service io;
int count = 0;
asio::deadline_timer t(io, boost::posix_time::seconds(1));
和上面一样,我们再一次使用了绑定asio::deadline_timer::async_wait()
t.async_wait(boost::bind(print,
asio::placeholders::error, &t, &count));
io.run();
asio::placeholders::error, &t, &count));
io.run();
在结尾,我们打印出的最后一次没有设置timer的调用的count的值
std::cout << "Final count is " << count << "\n";
return 0;
}
return 0;
}
完整的代码:
#include <iostream>
#include <asio.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
void print(const asio::error& /*e*/,
asio::deadline_timer* t, int* count)
{
if (*count < 5)
{
std::cout << *count << "\n";
++(*count);
t->expires_at(t->expires_at() + boost::posix_time::seconds(1));
t->async_wait(boost::bind(print,
asio::placeholders::error, t, count));
}
}
int main()
{
asio::io_service io;
int count = 0;
asio::deadline_timer t(io, boost::posix_time::seconds(1));
t.async_wait(boost::bind(print,
asio::placeholders::error, &t, &count));
io.run();
std::cout << "Final count is " << count << "\n";
return 0;
}
#include <asio.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
void print(const asio::error& /*e*/,
asio::deadline_timer* t, int* count)
{
if (*count < 5)
{
std::cout << *count << "\n";
++(*count);
t->expires_at(t->expires_at() + boost::posix_time::seconds(1));
t->async_wait(boost::bind(print,
asio::placeholders::error, t, count));
}
}
int main()
{
asio::io_service io;
int count = 0;
asio::deadline_timer t(io, boost::posix_time::seconds(1));
t.async_wait(boost::bind(print,
asio::placeholders::error, &t, &count));
io.run();
std::cout << "Final count is " << count << "\n";
return 0;
}
3.5. 成员函数作为回调函数
本例的运行结果和上一节类似
#include <iostream>
#include <boost/asio.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/asio.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
我们先定义一个printer类
class printer
{
public:
{
public:
构造函数有一个io_service参数,并且在初始化timer_时用到了它.用来计数的count_这里同样作为了成员变量
printer(boost::asio::io_service& io)
: timer_(io, boost::posix_time::seconds(1)),
count_(0)
{
: timer_(io, boost::posix_time::seconds(1)),
count_(0)
{
boost::bind 同样可以出色的工作在成员函数上.众所周知,所有的非静态成员函数都有一个隐式的this参数,我们需要把this作为参数bind到成员函数上.和上一 节类似,我们再次用bind构造出void(const boost::asio::error&)形式的函数.
注意,这里没有指定boost::asio::placeholders::error占位符,因为这个print成员函数没有接受一个error对象作为参数.
timer_.async_wait(boost::bind(&printer::print, this));
}
}
在类的折构函数中我们输出最后一次回调的conut的值
~printer()
{
std::cout << "Final count is " << count_ << "\n";
}
{
std::cout << "Final count is " << count_ << "\n";
}
print函数于上一节的十分类似,但是用成员变量取代了参数.
void print()
{
if (count_ < 5)
{
std::cout << count_ << "\n";
++count_;
timer_.expires_at(timer_.expires_at() + boost::posix_time::seconds(1));
timer_.async_wait(boost::bind(&printer::print, this));
}
}
private:
boost::asio::deadline_timer timer_;
int count_;
};
{
if (count_ < 5)
{
std::cout << count_ << "\n";
++count_;
timer_.expires_at(timer_.expires_at() + boost::posix_time::seconds(1));
timer_.async_wait(boost::bind(&printer::print, this));
}
}
private:
boost::asio::deadline_timer timer_;
int count_;
};
现在main函数清爽多了,在运行io_service之前只需要简单的定义一个printer对象.
int main()
{
boost::asio::io_service io;
printer p(io);
io.run();
return 0;
}
{
boost::asio::io_service io;
printer p(io);
io.run();
return 0;
}
完整的代码:
#include <iostream>
#include <boost/asio.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
class printer
{
public:
printer(boost::asio::io_service& io)
: timer_(io, boost::posix_time::seconds(1)),
count_(0)
{
timer_.async_wait(boost::bind(&printer::print, this));
}
~printer()
{
std::cout << "Final count is " << count_ << "\n";
}
void print()
{
if (count_ < 5)
{
std::cout << count_ << "\n";
++count_;
timer_.expires_at(timer_.expires_at() + boost::posix_time::seconds(1));
timer_.async_wait(boost::bind(&printer::print, this));
}
}
private:
boost::asio::deadline_timer timer_;
int count_;
};
int main()
{
boost::asio::io_service io;
printer p(io);
io.run();
return 0;
}
#include <boost/asio.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
class printer
{
public:
printer(boost::asio::io_service& io)
: timer_(io, boost::posix_time::seconds(1)),
count_(0)
{
timer_.async_wait(boost::bind(&printer::print, this));
}
~printer()
{
std::cout << "Final count is " << count_ << "\n";
}
void print()
{
if (count_ < 5)
{
std::cout << count_ << "\n";
++count_;
timer_.expires_at(timer_.expires_at() + boost::posix_time::seconds(1));
timer_.async_wait(boost::bind(&printer::print, this));
}
}
private:
boost::asio::deadline_timer timer_;
int count_;
};
int main()
{
boost::asio::io_service io;
printer p(io);
io.run();
return 0;
}
3.6. 多线程回调同步
本节演示了使用boost::asio::strand在多线程程序中进行回调同步(synchronise).
先 前的几节阐明了如何在单线程程序中用boost::asio::io_service::run()进行同步.如您所见,asio库确保 仅当 当前线程调用boost::asio::io_service::run()时产生回调.显然,仅在一个线程中调用 boost::asio::io_service::run() 来确保回调是适用于并发编程的.
一个基于asio的程序最好是从单线程入手,但是单线程有如下的限制,这一点在服务器上尤其明显:
- 当回调耗时较长时,反应迟钝.
- 在多核的系统上无能为力
如果你发觉你陷入了这种困扰,可以替代的方法是建立一个boost::asio::io_service::run()的线程池.然而这样就允许回调函数并发执行.所以,当回调函数需要访问一个共享,线程不安全的资源时,我们需要一种方式来同步操作.
#include <iostream>
#include <boost/asio.hpp>
#include <boost/thread.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/asio.hpp>
#include <boost/thread.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
在上一节的基础上我们定义一个printer类,此次,它将并行运行两个timer
class printer
{
public:
{
public:
除了声明了一对boost::asio::deadline_timer,构造函数也初始化了类型为boost::asio::strand的strand_成员.
boost::asio::strand 可以分配的回调函数.它保证无论有多少线程调用了boost::asio::io_service::run(),下一个回调函数仅在前一个回调函数完成 后开始,当然回调函数仍然可以和那些不使用boost::asio::strand分配,或是使用另一个boost::asio::strand分配的回 调函数一起并发执行.
printer(boost::asio::io_service& io)
: strand_(io),
timer1_(io, boost::posix_time::seconds(1)),
timer2_(io, boost::posix_time::seconds(1)),
count_(0)
{
: strand_(io),
timer1_(io, boost::posix_time::seconds(1)),
timer2_(io, boost::posix_time::seconds(1)),
count_(0)
{
当 一个异步操作开始时,用boost::asio::strand来 "wrapped(包装)"回调函数.boost::asio::strand::wrap()会返回一个由boost::asio::strand分配 的新的handler(句柄),这样,我们可以确保它们不会同时运行.
timer1_.async_wait(strand_.wrap(boost::bind(&printer::print1, this)));
timer2_.async_wait(strand_.wrap(boost::bind(&printer::print2, this)));
}
~printer()
{
std::cout << "Final count is " << count_ << "\n";
}
timer2_.async_wait(strand_.wrap(boost::bind(&printer::print2, this)));
}
~printer()
{
std::cout << "Final count is " << count_ << "\n";
}
多线程程序中,回调函数在访问共享资源前需要同步.这里共享资源是std::cout 和count_变量.
void print1()
{
if (count_ < 10)
{
std::cout << "Timer 1: " << count_ << "\n";
++count_;
timer1_.expires_at(timer1_.expires_at() + boost::posix_time::seconds(1));
timer1_.async_wait(strand_.wrap(boost::bind(&printer::print1, this)));
}
}
void print2()
{
if (count_ < 10)
{
std::cout << "Timer 2: " << count_ << "\n";
++count_;
timer2_.expires_at(timer2_.expires_at() + boost::posix_time::seconds(1));
timer2_.async_wait(strand_.wrap(boost::bind(&printer::print2, this)));
}
}
private:
boost::asio::strand strand_;
boost::asio::deadline_timer timer1_;
boost::asio::deadline_timer timer2_;
int count_;
};
{
if (count_ < 10)
{
std::cout << "Timer 1: " << count_ << "\n";
++count_;
timer1_.expires_at(timer1_.expires_at() + boost::posix_time::seconds(1));
timer1_.async_wait(strand_.wrap(boost::bind(&printer::print1, this)));
}
}
void print2()
{
if (count_ < 10)
{
std::cout << "Timer 2: " << count_ << "\n";
++count_;
timer2_.expires_at(timer2_.expires_at() + boost::posix_time::seconds(1));
timer2_.async_wait(strand_.wrap(boost::bind(&printer::print2, this)));
}
}
private:
boost::asio::strand strand_;
boost::asio::deadline_timer timer1_;
boost::asio::deadline_timer timer2_;
int count_;
};
main函数中boost::asio::io_service::run()在两个线程中被调用:主线程,一个boost::thread线程.
正如单线程中那样,并发的boost::asio::io_service::run()会一直运行直到完成任务.后台的线程将在所有异步线程完成后终结.
int main()
{
boost::asio::io_service io;
printer p(io);
boost::thread t(boost::bind(&boost::asio::io_service::run, &io));
io.run();
t.join();
return 0;
}
{
boost::asio::io_service io;
printer p(io);
boost::thread t(boost::bind(&boost::asio::io_service::run, &io));
io.run();
t.join();
return 0;
}
完整的代码:
#include <iostream>
#include <boost/asio.hpp>
#include <boost/thread.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
class printer
{
public:
printer(boost::asio::io_service& io)
: strand_(io),
timer1_(io, boost::posix_time::seconds(1)),
timer2_(io, boost::posix_time::seconds(1)),
count_(0)
{
timer1_.async_wait(strand_.wrap(boost::bind(&printer::print1, this)));
timer2_.async_wait(strand_.wrap(boost::bind(&printer::print2, this)));
}
~printer()
{
std::cout << "Final count is " << count_ << "\n";
}
void print1()
{
if (count_ < 10)
{
std::cout << "Timer 1: " << count_ << "\n";
++count_;
timer1_.expires_at(timer1_.expires_at() + boost::posix_time::seconds(1));
timer1_.async_wait(strand_.wrap(boost::bind(&printer::print1, this)));
}
}
void print2()
{
if (count_ < 10)
{
std::cout << "Timer 2: " << count_ << "\n";
++count_;
timer2_.expires_at(timer2_.expires_at() + boost::posix_time::seconds(1));
timer2_.async_wait(strand_.wrap(boost::bind(&printer::print2, this)));
}
}
private:
boost::asio::strand strand_;
boost::asio::deadline_timer timer1_;
boost::asio::deadline_timer timer2_;
int count_;
};
int main()
{
boost::asio::io_service io;
printer p(io);
boost::thread t(boost::bind(&boost::asio::io_service::run, &io));
io.run();
t.join();
return 0;
}
#include <boost/asio.hpp>
#include <boost/thread.hpp>
#include <boost/bind.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
class printer
{
public:
printer(boost::asio::io_service& io)
: strand_(io),
timer1_(io, boost::posix_time::seconds(1)),
timer2_(io, boost::posix_time::seconds(1)),
count_(0)
{
timer1_.async_wait(strand_.wrap(boost::bind(&printer::print1, this)));
timer2_.async_wait(strand_.wrap(boost::bind(&printer::print2, this)));
}
~printer()
{
std::cout << "Final count is " << count_ << "\n";
}
void print1()
{
if (count_ < 10)
{
std::cout << "Timer 1: " << count_ << "\n";
++count_;
timer1_.expires_at(timer1_.expires_at() + boost::posix_time::seconds(1));
timer1_.async_wait(strand_.wrap(boost::bind(&printer::print1, this)));
}
}
void print2()
{
if (count_ < 10)
{
std::cout << "Timer 2: " << count_ << "\n";
++count_;
timer2_.expires_at(timer2_.expires_at() + boost::posix_time::seconds(1));
timer2_.async_wait(strand_.wrap(boost::bind(&printer::print2, this)));
}
}
private:
boost::asio::strand strand_;
boost::asio::deadline_timer timer1_;
boost::asio::deadline_timer timer2_;
int count_;
};
int main()
{
boost::asio::io_service io;
printer p(io);
boost::thread t(boost::bind(&boost::asio::io_service::run, &io));
io.run();
t.join();
return 0;
}
3.7. TCP客户端:对准时间
#include <iostream>
#include <boost/array.hpp>
#include <boost/asio.hpp>
#include <boost/array.hpp>
#include <boost/asio.hpp>
本程序的目的是访问一个时间同步服务器,我们需要用户指定一个服务器(如time-nw.nist.gov),用IP亦可.
(译者注:日期查询协议,这种时间传输协议不指定固定的传输格式，只要求按照ASCII标准发送数据。)
using boost::asio::ip::tcp;
int main(int argc, char* argv[])
{
try
{
if (argc != 2)
{
std::cerr << "Usage: client <host>" << std::endl;
return 1;
}
int main(int argc, char* argv[])
{
try
{
if (argc != 2)
{
std::cerr << "Usage: client <host>" << std::endl;
return 1;
}
用asio进行网络连接至少需要一个boost::asio::io_service对象
boost::asio::io_service io_service;
我们需要把在命令行参数中指定的服务器转换为TCP上的节点.完成这项工作需要boost::asio::ip::tcp::resolver对象
tcp::resolver resolver(io_service);
一个resolver对象查询一个参数,并将其转换为TCP上节点的列表.这里我们把argv[1]中的sever的名字和要查询字串daytime关联.
tcp::resolver::query query(argv[1], "daytime");
节点列表可以用 boost::asio::ip::tcp::resolver::iterator 来进行迭代.iterator默认的构造函数生成一个end iterator.
tcp::resolver::iterator endpoint_iterator = resolver.resolve(query);
tcp::resolver::iterator end;
tcp::resolver::iterator end;
现在我们建立一个连接的sockert,由于获得节点既有IPv4也有IPv6的.所以,我们需要依次尝试他们直到找到一个可以正常工作的.这步使得我们的程序独立于IP版本
tcp::socket socket(io_service);
boost::asio::error error = boost::asio::error::host_not_found;
while (error && endpoint_iterator != end)
{
socket.close();
socket.connect(*endpoint_iterator++, boost::asio::assign_error(error));
}
if (error)
throw error;
boost::asio::error error = boost::asio::error::host_not_found;
while (error && endpoint_iterator != end)
{
socket.close();
socket.connect(*endpoint_iterator++, boost::asio::assign_error(error));
}
if (error)
throw error;
连接完成,我们需要做的是读取daytime服务器的响应.
我们用boost::array来保存得到的数据,boost::asio::buffer()会自动根据array的大小暂停工作,来防止缓冲溢出.除了使用boost::array,也可以使用char [] 或std::vector.
for (;;)
{
boost::array<char, 128> buf;
boost::asio::error error;
size_t len = socket.read_some(
boost::asio::buffer(buf), boost::asio::assign_error(error));
{
boost::array<char, 128> buf;
boost::asio::error error;
size_t len = socket.read_some(
boost::asio::buffer(buf), boost::asio::assign_error(error));
当服务器关闭连接时,boost::asio::ip::tcp::socket::read_some()会用boost::asio::error::eof标志完成, 这时我们应该退出读取循环了.
if (error == boost::asio::error::eof)
break; // Connection closed cleanly by peer.
else if (error)
throw error; // Some other error.
std::cout.write(buf.data(), len);
}
break; // Connection closed cleanly by peer.
else if (error)
throw error; // Some other error.
std::cout.write(buf.data(), len);
}
如果发生了什么异常我们同样会抛出它
}
catch (std::exception& e)
{
std::cerr << e.what() << std::endl;
}
catch (std::exception& e)
{
std::cerr << e.what() << std::endl;
}
运行示例:在windowsXP的cmd窗口下
输入:upload.exe time-a.nist.gov
输出:54031 06-10-23 01:50:45 07 0 0 454.2 UTC(NIST) *
完整的代码:
#include <iostream>
#include <boost/array.hpp>
#include <asio.hpp>
using asio::ip::tcp;
int main(int argc, char* argv[])
{
try
{
if (argc != 2)
{
std::cerr << "Usage: client <host>" << std::endl;
return 1;
}
asio::io_service io_service;
tcp::resolver resolver(io_service);
tcp::resolver::query query(argv[1], "daytime");
tcp::resolver::iterator endpoint_iterator = resolver.resolve(query);
tcp::resolver::iterator end;
tcp::socket socket(io_service);
asio::error error = asio::error::host_not_found;
while (error && endpoint_iterator != end)
{
socket.close();
socket.connect(*endpoint_iterator++, asio::assign_error(error));
}
if (error)
throw error;
for (;;)
{
boost::array<char, 128> buf;
asio::error error;
size_t len = socket.read_some(
asio::buffer(buf), asio::assign_error(error));
if (error == asio::error::eof)
break; // Connection closed cleanly by peer.
else if (error)
throw error; // Some other error.
std::cout.write(buf.data(), len);
}
}
catch (std::exception& e)
{
std::cerr << e.what() << std::endl;
}
return 0;
}
#include <boost/array.hpp>
#include <asio.hpp>
using asio::ip::tcp;
int main(int argc, char* argv[])
{
try
{
if (argc != 2)
{
std::cerr << "Usage: client <host>" << std::endl;
return 1;
}
asio::io_service io_service;
tcp::resolver resolver(io_service);
tcp::resolver::query query(argv[1], "daytime");
tcp::resolver::iterator endpoint_iterator = resolver.resolve(query);
tcp::resolver::iterator end;
tcp::socket socket(io_service);
asio::error error = asio::error::host_not_found;
while (error && endpoint_iterator != end)
{
socket.close();
socket.connect(*endpoint_iterator++, asio::assign_error(error));
}
if (error)
throw error;
for (;;)
{
boost::array<char, 128> buf;
asio::error error;
size_t len = socket.read_some(
asio::buffer(buf), asio::assign_error(error));
if (error == asio::error::eof)
break; // Connection closed cleanly by peer.
else if (error)
throw error; // Some other error.
std::cout.write(buf.data(), len);
}
}
catch (std::exception& e)
{
std::cerr << e.what() << std::endl;
}
return 0;
}
3.8. TCP同步时间服务器
#include <ctime>
#include <iostream>
#include <string>
#include <asio.hpp>
using asio::ip::tcp;
#include <iostream>
#include <string>
#include <asio.hpp>
using asio::ip::tcp;
我们先定义一个函数返回当前的时间的string形式.这个函数会在我们所有的时间服务器示例上被使用.
std::string make_daytime_string()
{
using namespace std; // For time_t, time and ctime;
time_t now = time(0);
return ctime(&now);
}
int main()
{
try
{
asio::io_service io_service;
{
using namespace std; // For time_t, time and ctime;
time_t now = time(0);
return ctime(&now);
}
int main()
{
try
{
asio::io_service io_service;
新建一个asio::ip::tcp::acceptor对象来监听新的连接.我们监听TCP端口13,IP版本为V4
tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 13));
这是一个iterative server,也就是说同一时间只能处理一个连接.建立一个socket来表示一个和客户端的连接, 然后等待客户端的连接.
for (;;)
{
tcp::socket socket(io_service);
acceptor.accept(socket);
{
tcp::socket socket(io_service);
acceptor.accept(socket);
当客户端访问服务器时,我们获取当前时间,然后返回它.
std::string message = make_daytime_string();
asio::write(socket, asio::buffer(message),
asio::transfer_all(), asio::ignore_error());
}
}
asio::write(socket, asio::buffer(message),
asio::transfer_all(), asio::ignore_error());
}
}
最后处理异常
catch (std::exception& e)
{
std::cerr << e.what() << std::endl;
}
return 0;
}
{
std::cerr << e.what() << std::endl;
}
return 0;
}
运行示例:运行服务器,然后运行上一节的客户端,在windowsXP的cmd窗口下
输入:client.exe 127.0.0.1
输出:Mon Oct 23 09:44:48 2006
完整的代码:
#include <ctime>
#include <iostream>
#include <string>
#include <asio.hpp>
using asio::ip::tcp;
std::string make_daytime_string()
{
using namespace std; // For time_t, time and ctime;
time_t now = time(0);
return ctime(&now);
}
int main()
{
try
{
asio::io_service io_service;
tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 13));
for (;;)
{
tcp::socket socket(io_service);
acceptor.accept(socket);
std::string message = make_daytime_string();
asio::write(socket, asio::buffer(message),
asio::transfer_all(), asio::ignore_error());
}
}
catch (std::exception& e)
{
std::cerr << e.what() << std::endl;
}
return 0;
}
#include <iostream>
#include <string>
#include <asio.hpp>
using asio::ip::tcp;
std::string make_daytime_string()
{
using namespace std; // For time_t, time and ctime;
time_t now = time(0);
return ctime(&now);
}
int main()
{
try
{
asio::io_service io_service;
tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 13));
for (;;)
{
tcp::socket socket(io_service);
acceptor.accept(socket);
std::string message = make_daytime_string();
asio::write(socket, asio::buffer(message),
asio::transfer_all(), asio::ignore_error());
}
}
catch (std::exception& e)
{
std::cerr << e.what() << std::endl;
}
return 0;
}
4. Filesystem Library 文件系统
推荐使用支持W3C标准的浏览器进行阅读，获得最佳页面效果，谢绝IE的混乱解析！
Searching all CPUG sites and mailist::
- Web
- getACL = 0.002s
- load_multi_cfg = 0.000s
- run = 0.402s
- send_page = 0.401s
- send_page_content = 0.349s
- total = 0.407s
ACE与ASIO之间关于Socket编程的比较
[收藏]ACE与ASIO之间关于Socket编程的比较
Joomla! 开源天空 作者：joomla 2008-08-05 21:41
* 摘要：[收藏]ACE与ASIO之间关于Socket编程的比较
*
ACE与ASIO之间关于Socket编程的比较
转自：FREE MY SOUL
ACE是一个很成熟的中间件产品，为自适应通讯环境，但它过于宏大，一堆的设计模式，架构是一层又一层，对初学者来说，有点困难。
ASIO是基本Boost开发的异步IO库，封装了Socket，简化基于socket程序的开发。
最近分析ASIO的源代码，让我无不惊呀于它设计。在ACE中开发中的内存管理一直让人头痛，ASIO的出现，让我看到新的曙光，成为我新的好伙伴。简单地与ACE做个比较。
1.层次架构：
ACE底层是C风格的OS适配层，上一层基于C++的wrap类，再上一层是一些框架（Accpetor, Connector，Reactor等），最上一层是框架上服务。
ASIO与之类似，底层是OS的适配层，上一层一些模板类，再上一层模板类的参数化（TCP/UDP），再上一层是服务，它只有一种框架为io_service。
2.涉及范围：
ACE包含了日志，IPC，线程，共享内存，配置服务等。
ASIO只涉及到Socket，提供简单的线程操作。
3.设计模式：
ACE主要应用了Reactor，Proactor等。
而ASIO主要应用了Proactor。
4.线程调度：
ACE的Reactor是单线程调度，Proactor支持多线程调度。
ASIO支持单线程与多线程调度。
5.事件分派处理：
ACE主要是注册handler类，当事件分派时，调用其handler的虚挂勾函数。实现ACE_Handler/ACE_Svc_Handler/ACE_Event_handler等类的虚函数。
ASIO是基于函数对象的hanlder事件分派。任何函数都可能成功hanlder，少了一堆虚表的维护，调度上优于ACE。
6.发布方式：
ACE是开源免费的，不依赖于第3方库， 一般应用使用它时，以动态链接的方式发布动态库。
ASIO是开源免费的，依赖Boost，应用使用时只要include头文件，不需动态库。
7.可移植性：
ACE支持多种平台，可移植性不存在问题，据说socket编程在linux下有不少bugs。
ASIO支持多种平台，可移植性不存在问题。
8.开发难度：
基于ACE开发应用，对程序员要求比较高，要用好它，必须非常了解其框架。在其框架下开发，往往new出一个对象，不知在什么地方释放好。
基于ASIO开发应用，要求程序员熟悉函数对象，函数指针，熟悉boost库中的boost::bind。内存管理控制方便。
我个人觉得，如果应用socket编程，使用ASIO开发比较好，开发效率比较高。ACE适合于理论研究，它本来就是源于Douglas的学术研究。
Joomla! 开源天空 作者：joomla 2008-08-05 21:41
* 摘要：[收藏]ACE与ASIO之间关于Socket编程的比较
*
ACE与ASIO之间关于Socket编程的比较
转自：FREE MY SOUL
ACE是一个很成熟的中间件产品，为自适应通讯环境，但它过于宏大，一堆的设计模式，架构是一层又一层，对初学者来说，有点困难。
ASIO是基本Boost开发的异步IO库，封装了Socket，简化基于socket程序的开发。
最近分析ASIO的源代码，让我无不惊呀于它设计。在ACE中开发中的内存管理一直让人头痛，ASIO的出现，让我看到新的曙光，成为我新的好伙伴。简单地与ACE做个比较。
1.层次架构：
ACE底层是C风格的OS适配层，上一层基于C++的wrap类，再上一层是一些框架（Accpetor, Connector，Reactor等），最上一层是框架上服务。
ASIO与之类似，底层是OS的适配层，上一层一些模板类，再上一层模板类的参数化（TCP/UDP），再上一层是服务，它只有一种框架为io_service。
2.涉及范围：
ACE包含了日志，IPC，线程，共享内存，配置服务等。
ASIO只涉及到Socket，提供简单的线程操作。
3.设计模式：
ACE主要应用了Reactor，Proactor等。
而ASIO主要应用了Proactor。
4.线程调度：
ACE的Reactor是单线程调度，Proactor支持多线程调度。
ASIO支持单线程与多线程调度。
5.事件分派处理：
ACE主要是注册handler类，当事件分派时，调用其handler的虚挂勾函数。实现ACE_Handler/ACE_Svc_Handler/ACE_Event_handler等类的虚函数。
ASIO是基于函数对象的hanlder事件分派。任何函数都可能成功hanlder，少了一堆虚表的维护，调度上优于ACE。
6.发布方式：
ACE是开源免费的，不依赖于第3方库， 一般应用使用它时，以动态链接的方式发布动态库。
ASIO是开源免费的，依赖Boost，应用使用时只要include头文件，不需动态库。
7.可移植性：
ACE支持多种平台，可移植性不存在问题，据说socket编程在linux下有不少bugs。
ASIO支持多种平台，可移植性不存在问题。
8.开发难度：
基于ACE开发应用，对程序员要求比较高，要用好它，必须非常了解其框架。在其框架下开发，往往new出一个对象，不知在什么地方释放好。
基于ASIO开发应用，要求程序员熟悉函数对象，函数指针，熟悉boost库中的boost::bind。内存管理控制方便。
我个人觉得，如果应用socket编程，使用ASIO开发比较好，开发效率比较高。ACE适合于理论研究，它本来就是源于Douglas的学术研究。
2009年3月22日星期日
mingw手工编译wxWidgets遇到的奇怪问题，及解决方案收藏
http://blog.csdn.net/DelphiNew/archive/2007/05/11/1605310.aspx
要使用wxWidgets来开发界面，
要使用wxWidgets来开发界面，
没有打算省力，所以下载的是源程序，自已编译。。。。
编译器和make程序用的是dev-c++中带的mingw。。。。
然而在make 时，发生这个错误信息
if not exist ..\..\lib\gcc_lib\mswd\wx mkdir ..\..\lib\gcc_lib\mswd\wx
/usr/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [..\..\lib\gcc_lib\mswd\wx] Error 2
明明自己的c:\devc\bin目录已经在path的最前位了呀？how come？
一开始也不明白，明明用的是win32版的mingw，怎么会以用到/usr/bin/sh呢？？？
现在也真不是看make的源代码的时候，，
瞎猜可能是因为在path中其它的cygwin工具影响了吧。。。那么我们狠一点
set path=c:\devc\bin
make -f makefile.gcc
成功了。。。。
一下子觉得自己又笨又恶心~
编译器和make程序用的是dev-c++中带的mingw。。。。
然而在make 时，发生这个错误信息
if not exist ..\..\lib\gcc_lib\mswd\wx mkdir ..\..\lib\gcc_lib\mswd\wx
/usr/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [..\..\lib\gcc_lib\mswd\wx] Error 2
明明自己的c:\devc\bin目录已经在path的最前位了呀？how come？
一开始也不明白，明明用的是win32版的mingw，怎么会以用到/usr/bin/sh呢？？？
现在也真不是看make的源代码的时候，，
瞎猜可能是因为在path中其它的cygwin工具影响了吧。。。那么我们狠一点
set path=c:\devc\bin
make -f makefile.gcc
成功了。。。。
一下子觉得自己又笨又恶心~
安装wxWidgets （http://www.d2school.com/bhcpp_book/2_4.php）
2.4. 安装wxWidgets
多数应用软件，通常需要一个界面与使用者进行交互。典型的交互方式可以分成三种：
- 纯文字界面
也称为“控制台”应用。此类应用通过以“一问一答”的形式在屏幕上打出提问的文字，然后等待用户输入后，程序得以继续运行。 这类交互形式称不上友好，但实现起来简单。在我们学习C++语法的一个很长的时期，我们所写的程序，多数采用此类形式。 - 图形用户界面
通过“对话框”、“菜单”、“按钮”等典型的图形元素所提供的用户界面。即“图形用户界面／Graphical user interface”，简称为GUI。该形式下，用户通过鼠标或键盘操作，选择所需的功能。 我们常用Office软件、QQ聊天软件、以及Windows操作系统本身，都是典型的GUI程序。 - 浏览器界面
浏览器界面是GUI的一种特定应用。它将程序分为后台服务和前台展示两部分。后台服务主要实现程序的业务逻辑，以及产生界面脚本（通常是HTML），真正 的界面展现与交互工作完全交给第三方的浏览器（比如IE,或Firefox）去完成。 当我们上网浏览新闻时，就是在使用此类应用。
本书前面的一大部分内容，采用“纯文字界面”作为范例程序主要采用界面方式。此安排自然是为了避免读者一开始就陷入复杂的GUI界面设计的“泥潭”之中。然而，与大多数纯粹的C++语言教程止步于此不同，如果编写（跨平台）的“图形用户界面”，也是本书的主要教学内容。
C++ 的GUI程序库，同样充满很多选择。一些非开源产品多数仅限于某一平台。wxWidgets是同时符合“开源”、“成熟”、“跨平台”，并且支持各平台“ 原生界面”的GUI库中的佼佼者。这里的“原生界面”是指，在A系统下，其生成的界面元素，就和A系统的本地界面风格一致，这里的A，可以指代 Windows XP、也可以指代Linux下某一图形界面。
wxWidgets的主要特点如下：
- 开源
- 跨平台：Windows、Mac OS X、GTK+、X11、Motif、WinCE。
- 既支持原生界面，也支持统一风格界面。
- 不仅仅是图形界面库：集成提供了包括文件操作、目录操作、多线程、网络通讯、OpenGL（3D）等等功能库。
- 支持不同的库链接形式：静态链接，动态链接库，其中后者还可以支持编译成单一动态库，或多个小动态库的形式。
- 支持UNICODE：编译时，可以编译出UNICODE或非UNICODE两种版本，本书采用UNICODE，以方便编程上对汉字的操作。
- 发展成熟：有较长的发展历史（起源于1992年），业界有许多基于wxWidgets的成熟应用
- 学习资源丰富：网络上的可以找到较多的资源。
- 与Code::Blocks结合紧密：C::B本身正是采用wxWidgets实现跨平台的图形用户界面。另外C::B内置了使用wxWidgets的可视界面设计工具。
- 支持多种编译器：包括本书采用的开源gcc/g++编译器，也包括Visual C++等商业编译器。
本书配套光盘提供了wxWidgets 2.8.8 版本的安装程序，以及四种编译库。您可以通过查看光盘中对应的说明文件，实现快速安装。
如果您需要更新版本的wxWidgets，或者您只是想学习其编译过程，那么请继续阅读下述内容。
2.4.1. 准备
请通过本小节末尾的“相关网站”链接，上网下载wxWidgets的最新稳定版本。请注意选择为for windows版本。
下载得到的，应是一个可执行的安装程序。与Code::Blocks的安装类似，建议将其安装某个驱动器的根目录下，比如：E:\ wxWidgets-2.8.8 目录下（尾部数字以您所使用的wxWidgets版本为准）。
当然，由于本书将指导您安装多个C++扩展库，因此，如果您愿意建立一个新文件夹，用于作为各个C++扩展库的统一的父文件夹，的确是个好主意。
2.4.2. 编译
上一步安装wxWidgets，仅得到源代码文件及一些说明。我们还需要将其中的源代码编译成“库”文件。此类“库”有很多种形式，但其实都可以称为“预编译库”。意思是：它们已经编译好了，你直接拿去用吧。
我们先简单地了解一下“动态、静态”及“调试、发行”的区别。
“库”通常包含很多功能代码，但它们本身并不能直接运行，而是准备提供给应用程序使用， “动态链接”和“静态链接”代表程序如何找到及使用库功能的两种不同方法。
“静态链接”是指，直接将库文件和程序文件合成一个大文件，在合并过程中，完成对库文件各个功能的定位。这个事情发生程序编译的过程。
“动态链接”与此相反，库文件和程序文件各自独立存在，程序在运行时，才去库文件找相关的功能。
完全使用“静态链接”，我们可能会得到一个“胖胖”的程序，直接发给用户使用就可以了。使用“动态链接”，我们可能需要分发给你的用户多个文件（程序和各个库文件）。不小心弄丢了哪个文件，用户们就要抱怨你的软件“跑”不起来了。
“调试版”和“发行版”就和链接技术无关了。前者表示，二者的区别在于：前者含有调试信息，而后者没有。有调试信息有利于我们纠出程序中的错误，不过既然它的含有额外的信息，所以这样的库肯定“胖”了不少。如果觉得错误纠得差不多了，我们就可以改用相对“苗条”的发行版。
有关“库”的详细知识，我们留在第四章讲。今天我们将把wxWidgets编译译成四种形式：
- 动态链接库 ＋ 调试版
- 动态链接库 ＋ 发行版
- 静态链接库 ＋ 调试版
- 静态链接库 ＋ 发行版
另 外，wxWidgets的编译，还可以区分“UNICODE”及“非 UNICODE”两种式。在多数场合下，“UNICODE”可以对汉字及国际化有较方便的支持。因此以上四种组合，我们全部都加上相同“UNICODE” 选项。当然， “非UNICODE”选项倒也不是一无是处，以后我们也会用到。
正式开始编译之前，必须确保已经在电脑上正确安装好mingw32环境，如果您不在确信，请使用2.1.6.1小节中提及的方法进行检测。
(以下四个版本都需要编译，而不是仅编译其一。)
- 静态链接（调试版）
步骤1：打开“开始”菜单：“所有程序→附件→记事本”程序。用它打开 wxWidgets安装目录下，子目录“build\msw\”下面的“config.gcc”文件。
步骤2：找到以下内容，并确保将等号(:=)后面的值如下面加粗内容所示。另外其它未指部分的内容，请保持不变。
步骤3：请确认保存了本步的修改成果，再继续下一步。
# What type of library to build? [0,1] # Compile Unicode build of wxWidgets? [0,1] # Type of compiled binaries [debug,release] |
步骤4：SHARED 为 0表示要编译的是静态库，而不是动态库（共享库）；
UNICODE为1，表示要编译成UNICODE版本，这一项在本次编译过程中始终为1。
BUILD为debug，表示要编译成含有调试信息的版本。
步骤5：打开“开始”菜单，选择“运行”，输入cmd，进入控制台窗口，然后在其内通过cd命令，切换到wxWidgets安装目录下的“build\msw”路径。比如您把wxWidgets 安装在“E:\wxWidgets-2.8.8”，则过程如下：
E: (回车)
cd wxWidgets-2.8.8 (回车)
cd build\msw (回车)
步骤6：在第3步的控制台中，继续输入以下命令：
mingw32-make.exe -f makefile.gcc (回车)
步骤7：这将开始一段长约30分钟的编译过程（视你的机器配置而定）。
- 静态链接（发行版）
编译过程和前一版本主要差别在于“config.gcc”文件的修改内容：
# What type of library to build? [0,1] # Compile Unicode build of wxWidgets? [0,1] |
其它操作方法不变。
- 动态链接（调试版）
编译过程和前一版本主要差别在于“config.gcc”文件的修改内容：
# What type of library to build? [0,1] # Type of compiled binaries [debug,release] |
其它操作方法不变。
- 动态链接（发行版）
编译过程和前一版本主要差别在于“config.gcc”文件的修改内容：
# Type of compiled binaries [debug,release] |
其它操作方法不变。
2.4.3. 结束
这是一次漫长的编译过程，至此，我们完成了四个版本的wxWidgets库的编译。它是我们编写图形用户界面基础。
为 了确保大家尽量顺利地完成编译，我们在“config.gcc”仅选择了最基本的编译选项。因此一些强大wxWidgets功能模块没有被编译成库，比如 前面提到的非Unicode版，另外没有支持OpenGL、OBDC等功能。后面需要时，我们将会加上，并且令大家放心的是，这并不会带来又一次 wxWidgets漫长完全编译。
每次30分钟的编译过程，漫长的等待中，我猜到您不耐烦得站起来四处走动。走动其实健康有益。然而，在程序员的生涯中，我们更多面临的，可能是无数个3分钟，甚至是30秒的等待，这时，你是否记得提醒自己也要常常起来走动走动？
Code::Blocks专门提供一个插件，用于提醒程序员注意休息，很有兴趣?请在休息之后继续我们的白话之旅。
编 译过程中会产生大量的中间临时文件。请进入wxWidgets文件夹内的“build”子文件夹，搜索 “*.o”文件（确保选中“搜索子文件夹”选项）：约有3千多个中间文件，全部删除，可以腾出1G多的空间。（Windows下多数编译器会生产扩展名为 “.obj”的文件，但mingw32-g++产生的为“.o”文件。）
编译完成后，所有静态链接库位于wxWidgets安装目录下的“lib\gcc_lib”子目录。而动态链接库位于 “lib\gcc_dll”子目录。
仔细观察，会发现库文件名称中，有不少带有“ud”字母的文件，其中‘d’表示“debug”，即调试版本 ，不带‘d’的通常是“release”版本。
‘u’表示“Unicode”，即支持Unicode编码。虽然我们这一次编译的全部采用“Unicode”选项，但还是存在一些文件并不带‘u’字母，那是因为这些库并不涉及到字符串的国际化处理，所以不需要考虑编码，比如与Jpeg图形功能有关的库。
- 静态库文件
libwxbase28u.a |
- 动态库文件
wxbase28ud_gcc_custom.dll wxbase28ud_net_gcc_custom.dll |
在gcc_dll目录下，除了扩展名为“.dll”的动态链接库以外，还存在大量的扩展为“.a”的文件，称为“导入库／Import library”，为了节省篇幅，上表未加列出。
“导入库”在编译时向应用程序提供信息，以辅助应用程序在运行时，定位具体某一功能在DLL文件中的入口。也就是说，今后编译程序时，将用到它们，但它们不必随同程序一起发行。
2.4.4. 相关网址
wxWidgets 官方网站：www.wxWidgets.org
wxWidgets扩展代码：www.wxCode.com
2009年3月18日星期三
GLADE/GTK在WIN下的编译
0
标签： GTK+ 软件开发
GLADE/GTK在WIN下的编译
哎，本来了自己是喜欢搞硬件的，偏偏这段时间实习却去了家软件为主的公司，现在成了一个菜鸟级的代码员了，离自己的梦想越来越远了。看来在工作之余确实要拿出时间来搞搞自己喜欢的东西才行。
这段时间在搞QT。为什么用QT呢？呵呵应为项目前期别人用QT编好了，要我接过来，我总不可能拿过来就全部改写吧？再说我现在也还没有那样的能力呢呵呵。QT确实不好，开源的仅限于学习之用，要开发商业版的软件，那可是要付出巨额费用购买商业版的，呵呵在中国也罢，满天飞的D版，谁来管。呵呵反正我是不怎么学习QT的。有QT当然就有相对的GTK呢，呵呵GTK也是刚学，相比以后嵌入式上的编程也用的到，用了开源的库当然要找个开源的IDE啊（当然N 人用GCC+MinGw编呵呵）呵呵，用的多的可能是DEV_CPP了，不过那都是N年前的东西了，最近找了个CODE::BLOKDS呵呵界面美观和 VS差不多的漂亮，而且代码提示功能很全，调试也很到位，可以用多种编译器，呵呵它的好处只要你用GOOGLE一搜就找到了，我就不在这里费口舌了。
首先要下WIN下的MinGw和GTK+，最方便的是到SOURCEFORGE上去找auto MinGW和GTK+ FOR WIN32的包，下下来是可执行文件，一按好就全部OK了，我这里是自己下一个个的Win下的包，一个个解压安装的，安装方法我也不说了到GOOGLE上有很多的，这里解决一个问题，就是：
安装GLADE3后用其画一个简单的文本框，
关于以GLADE3的使用：
引用"简单为美"博客，这里对博主表示感谢
原文地址：http://www.cppblog.com/len/archive/2008/03/27/45548.aspx
Say Hello to Glade
Glade是针对GTK+工具箱与 GNOME桌面开发环境的快速图形界面开发工具.用Glade设计的用户接口以XML的文件形式保存,然后根据需要由程序通过libglade库文件来动态加载.因为使用了libglade库,Glade XML文件能够被C,C++,Java,Perl,Python,C#等等语言所支持.针对其他未涉及的语言的支持也是方便的.
在网上可以见到某些关于Glade的教程,大都是关于Linux平台和Glade 2的,因为原先Glade作为快速开发工具,集成代码生成功能,生成C文件.所以常常有初学者对网上某些教程所提及的"generate"(生成代码)功能表示迷惑,在新版本的Glade-3上找不到对应的功能.
新版本的Glade-3是对原先 Glade代码的完全重写.一个显著的变化就是去除了代码生成功能.这样做是有原因的,即然代码生成功能不被提倡使用,而是更鼓励使用libglade功能.但是如果你真需要代码生成功能的话,它还是可以做为插件来提供的.另一个显著的不同是glade-3设计用来最大化使用GObject的自省机制 (GObject introspection),来使外部工具箱和部件的控制,信号和属性的集成更加容易.
如果看过Say Hello to GTK+的话，可能感觉那样的窗体程序太简单了．那么现在让我们借助Glade弄点儿复杂一点儿的界面吧．首先来瞧瞧Glade长什么样,下图就是Glade在windows下的界面.左边的窗体的小部件选择器，相当于调色板．中间是主菜单，右边的是属性窗体．
点击看大图
现在开始创建一个类似于文本编辑器的图形界面．按照上图标注的顺序，依次添加window部件，vertical box部件,menu bar部件,text view部件和Status部件.vertical box设置三行，它是用来进行界面布局，分割空间用，这是gtk+设计与传统的windows UI设计很不同的地方．后三个部件是放置vertical box中的，最后设计完成图形如下．保存取名为win.glade.如果你感兴趣的话，可以用文件编辑器打开这个文件看看，正如所说的那样，它是一个 xml格式的文本文件．
win
现在我们设置相关的头文件和库文件，编辑一个glade.c文件，添加进以下的代码，运行看看，会出现如上图的对话框．虽然这个对话框什么都不干，但是通过Glade，我们能较为容易地设计界面，而不用通过gtk函数，一个一个将控件实现.
#include <gtk/gtk.h>
#include <glade/glade.h>
int main(int argc, char* argv[])
{
GladeXML *gxml;
GtkWidget *window;
gtk_init (&argc, &argv);
gxml = glade_xml_new ("win.glade", NULL, NULL);
window = glade_xml_get_widget (gxml, "hello");
g_object_unref (G_OBJECT (gxml));
gtk_widget_show (window);
gtk_main ();
return 0;
}
保存为win.glade的XML文件。可以看到顶层的窗口物件被自动命名为window1；在codeblocks中建立GTK工程将main.c文件的内容改为
#include <gtk/gtk.h>
#include <glade/glade.h>
int main(int argc, char* argv[])
{
GladeXML *gxml;
GtkWidget *window;
gtk_init (&argc, &argv);
gxml = glade_xml_new ("win.glade",NULL,NULL);
window = glade_xml_get_widget(gxml, "window1");
g_object_unref (G_OBJECT (gxml));
gtk_widget_show (window);
gtk_main ();
return 0;
}
编译，出现几个错误：
1、#include <glade/glade.h>里面的glade.h找不到
2、glade_xml_new 和glade_xml_get_widget有未定义的参数
（前提是你gtk中有libglade库和libxml2库，如果没有的话去sourceforge上去找到win版本下下来，也可以到MinGW的网站，然后进到Download里面，再找到相应的包下下来解压）
但是在MSYS下进入到项目的目录下，敲入gcc -o glade main.c `pkg-config --cflags --libs gtk+-2.0 libglade-2.0`竟然成功生成了glade.exe文件，运行一看正是那个画好的界面，哦！呵呵看来并不是环境的原因，也不是程序的原因了，应该是codeblocks的设置问题了，继续到网上找答案，没办法中文资料太少了只要到 codeblocks的官方论坛找了。
费率一番周折终于搞定了，呵呵其实很简单，引用论坛原帖：
EUREKA!!!!
adding in Project / Build options / linker/ other options
`pkg-config --cflags gtk+-2.0`
`pkg-config --libs gtk+-2.0`
WORKS !
thank you very much
原来就是把pkg-config的--cflags和--libs参数分开来写就可以了，注意这里是关键，网上很多介绍的方法并没有把它分成两次来写，而是像在Linux里一样写成一行了，写在一个``里面了，那样是不行的。
当然了在Project / Build options / compiler/ other options下面也是要加的呵呵！
标签： GTK+ 软件开发
GLADE/GTK在WIN下的编译
哎，本来了自己是喜欢搞硬件的，偏偏这段时间实习却去了家软件为主的公司，现在成了一个菜鸟级的代码员了，离自己的梦想越来越远了。看来在工作之余确实要拿出时间来搞搞自己喜欢的东西才行。
这段时间在搞QT。为什么用QT呢？呵呵应为项目前期别人用QT编好了，要我接过来，我总不可能拿过来就全部改写吧？再说我现在也还没有那样的能力呢呵呵。QT确实不好，开源的仅限于学习之用，要开发商业版的软件，那可是要付出巨额费用购买商业版的，呵呵在中国也罢，满天飞的D版，谁来管。呵呵反正我是不怎么学习QT的。有QT当然就有相对的GTK呢，呵呵GTK也是刚学，相比以后嵌入式上的编程也用的到，用了开源的库当然要找个开源的IDE啊（当然N 人用GCC+MinGw编呵呵）呵呵，用的多的可能是DEV_CPP了，不过那都是N年前的东西了，最近找了个CODE::BLOKDS呵呵界面美观和 VS差不多的漂亮，而且代码提示功能很全，调试也很到位，可以用多种编译器，呵呵它的好处只要你用GOOGLE一搜就找到了，我就不在这里费口舌了。
首先要下WIN下的MinGw和GTK+，最方便的是到SOURCEFORGE上去找auto MinGW和GTK+ FOR WIN32的包，下下来是可执行文件，一按好就全部OK了，我这里是自己下一个个的Win下的包，一个个解压安装的，安装方法我也不说了到GOOGLE上有很多的，这里解决一个问题，就是：
安装GLADE3后用其画一个简单的文本框，
关于以GLADE3的使用：
引用"简单为美"博客，这里对博主表示感谢
原文地址：http://www.cppblog.com/len/archive/2008/03/27/45548.aspx
Say Hello to Glade
Glade是针对GTK+工具箱与 GNOME桌面开发环境的快速图形界面开发工具.用Glade设计的用户接口以XML的文件形式保存,然后根据需要由程序通过libglade库文件来动态加载.因为使用了libglade库,Glade XML文件能够被C,C++,Java,Perl,Python,C#等等语言所支持.针对其他未涉及的语言的支持也是方便的.
在网上可以见到某些关于Glade的教程,大都是关于Linux平台和Glade 2的,因为原先Glade作为快速开发工具,集成代码生成功能,生成C文件.所以常常有初学者对网上某些教程所提及的"generate"(生成代码)功能表示迷惑,在新版本的Glade-3上找不到对应的功能.
新版本的Glade-3是对原先 Glade代码的完全重写.一个显著的变化就是去除了代码生成功能.这样做是有原因的,即然代码生成功能不被提倡使用,而是更鼓励使用libglade功能.但是如果你真需要代码生成功能的话,它还是可以做为插件来提供的.另一个显著的不同是glade-3设计用来最大化使用GObject的自省机制 (GObject introspection),来使外部工具箱和部件的控制,信号和属性的集成更加容易.
如果看过Say Hello to GTK+的话，可能感觉那样的窗体程序太简单了．那么现在让我们借助Glade弄点儿复杂一点儿的界面吧．首先来瞧瞧Glade长什么样,下图就是Glade在windows下的界面.左边的窗体的小部件选择器，相当于调色板．中间是主菜单，右边的是属性窗体．
点击看大图
现在开始创建一个类似于文本编辑器的图形界面．按照上图标注的顺序，依次添加window部件，vertical box部件,menu bar部件,text view部件和Status部件.vertical box设置三行，它是用来进行界面布局，分割空间用，这是gtk+设计与传统的windows UI设计很不同的地方．后三个部件是放置vertical box中的，最后设计完成图形如下．保存取名为win.glade.如果你感兴趣的话，可以用文件编辑器打开这个文件看看，正如所说的那样，它是一个 xml格式的文本文件．
win
现在我们设置相关的头文件和库文件，编辑一个glade.c文件，添加进以下的代码，运行看看，会出现如上图的对话框．虽然这个对话框什么都不干，但是通过Glade，我们能较为容易地设计界面，而不用通过gtk函数，一个一个将控件实现.
#include <gtk/gtk.h>
#include <glade/glade.h>
int main(int argc, char* argv[])
{
GladeXML *gxml;
GtkWidget *window;
gtk_init (&argc, &argv);
gxml = glade_xml_new ("win.glade", NULL, NULL);
window = glade_xml_get_widget (gxml, "hello");
g_object_unref (G_OBJECT (gxml));
gtk_widget_show (window);
gtk_main ();
return 0;
}
保存为win.glade的XML文件。可以看到顶层的窗口物件被自动命名为window1；在codeblocks中建立GTK工程将main.c文件的内容改为
#include <gtk/gtk.h>
#include <glade/glade.h>
int main(int argc, char* argv[])
{
GladeXML *gxml;
GtkWidget *window;
gtk_init (&argc, &argv);
gxml = glade_xml_new ("win.glade",NULL,NULL);
window = glade_xml_get_widget(gxml, "window1");
g_object_unref (G_OBJECT (gxml));
gtk_widget_show (window);
gtk_main ();
return 0;
}
编译，出现几个错误：
1、#include <glade/glade.h>里面的glade.h找不到
2、glade_xml_new 和glade_xml_get_widget有未定义的参数
（前提是你gtk中有libglade库和libxml2库，如果没有的话去sourceforge上去找到win版本下下来，也可以到MinGW的网站，然后进到Download里面，再找到相应的包下下来解压）
但是在MSYS下进入到项目的目录下，敲入gcc -o glade main.c `pkg-config --cflags --libs gtk+-2.0 libglade-2.0`竟然成功生成了glade.exe文件，运行一看正是那个画好的界面，哦！呵呵看来并不是环境的原因，也不是程序的原因了，应该是codeblocks的设置问题了，继续到网上找答案，没办法中文资料太少了只要到 codeblocks的官方论坛找了。
费率一番周折终于搞定了，呵呵其实很简单，引用论坛原帖：
EUREKA!!!!
adding in Project / Build options / linker/ other options
`pkg-config --cflags gtk+-2.0`
`pkg-config --libs gtk+-2.0`
WORKS !
thank you very much
原来就是把pkg-config的--cflags和--libs参数分开来写就可以了，注意这里是关键，网上很多介绍的方法并没有把它分成两次来写，而是像在Linux里一样写成一行了，写在一个``里面了，那样是不行的。
当然了在Project / Build options / compiler/ other options下面也是要加的呵呵！
2009年3月17日星期二
Code::Blocks，更好的跨平台C/C++集成开发环境
Code::Blocks
[编辑本段]
介绍
Code::Blocks 是一个开放源码的全功能的跨平台C/C++集成开发环境.
相比于基于Delphi的Dev-C++共享C++IDE，Code::Blocks是开放源码软件。Code::Blocks由纯粹的C++语言开发完成，它使用了蓍名的图形界面库wxWidgets(2.6.2 unicode)版。对于追求完美的C++程序员，再也不必忍受Eclipse的缓慢，再也不必忍受VS.NET的庞大和高昂的价格。
虽然Code::Blocks从一开始就追求跨平台目标，但是最初的开发重点是Windows 系统下的版本，从06年3月21日版本：1.0 revision 2220开始，Code::Blocks在它的每日构建中正式提供Linux版本（分两个版本：ubuntu.deb和fc4.rpm）。这样 Code::Blocks在1.0发布时就会是跨越平台的C/C++IDE，它将支持Windows和Linux的主要版本。长期以来C++开发员在 Linux没有好用、通用的C++ IDE的局面就要结束。而这个IDE对于Windows下的用户同样重要，由于它开放源码的特点，Windows用户可以不依赖于VS.NET，编写跨平台C++应用。
Code::Blocks提供了许多工程模板，这包括：控制台应用、DirectX应用、动态连接库、FLTK应用、GLFW应用、Irrlicht工程、OGRE应用、OpenGL应用、QT应用、SDCC应用、SDL应用、SmartWin应用、静态库、Win32 GUI应用、wxWidgets应用、wxSmith工程，另外它还支持用户自定义工程模板。在wxWidgets应用中选择UNICODE支持中文。
Code::Blocks支持语法彩色醒目显示，支持代码完成（目前正在重新设计过程中）支持工程管理、项目构建、调试。
Code::Blocks支持插件，目前的插件包括代码格式化工具AStyle；代码分析器；类向导；代码补全；代码统计；编译器选择；复制字符串到剪贴板；调试器；文件扩展处理器；Dev-C++ DevPak更新/安装器；DragScroll，源码导出器，帮助插件，键盘快捷键配置，插件向导；To-Do列表；wxSmith；；wxSmith MIME插件；wsSmith工程向导插件；WindowsXP外观。
Code::Blocks具有灵活而强大的配置功能，除支持自身的工程文件、C/C++文件外，还支持AngelScript、批处理、CSS文件、D语言文件、Diff/Patch文件、Fortan77文件、GameMonkey脚本文件、 Hitachi汇编文件、Lua文件、MASM汇编文件、Mathlab文件、NSIS开源安装程序文件、Ogre Compositor脚本文件、Ogre Material脚本文件、OpenGL Shading语言文件、Python文件、Windows资源文件、XBase文件、XML文件、nVidia cg文件。识别Dev-C++工程、MS VS 6.0-7.0工程文件，工作空间、解决方案文件。
Code::Blocks基于wxWidgets开发，正体现了wxWidgets的强大。以前Borland C++ Builder X宣称基于wxWidgets开发跨平台、兼容性好、最优秀的C++ IDE环境，但没有实现；现在Code::Blocks+GNU GCC正在实现这个理想。让我们拭目以待。国内的Code::Blocks爱好者和跨平台开发员应该尽快建立中文Code::Blocks网站，提供 Code::Blocks中文化支持，促进Code::Blocks在国内的发展。
[编辑本段]
安装
2.1安装Code::Blocks发行版 8.02
8.02版是必须安装的，然后才能升级。
2.11 下载安装文件
Code::Blocks的发行版版本号就是它的发行年月，所以8.02版，就是08年2月份发布的，其实地相当于1.0版。
Code::Blocks网站：www.codeblocks.org 其下载页面（http://www.codeblocks.org/downloads/5）提供了windows,Linux(多个发行版)，及Mac OS X 的安装文件或源文件包。 不过我们暂时只讲Windows下的安装。所以您可以将下面的链接，复制到迅雷之类的工具下载。
2.12 卸载可能的mingw32先前版本
Code::Blocks支持多种编译器，但我们主要讲Windows下的mingw32 g++编译器。因此需要安装mingw32。前面下载的安装程序已经自带有完整的mingw32环境。mingw32是g++环境在windows下的一个实现。为了避免版本与路径冲突，最好不要在一台机器上安装两个mingw32。所以本步要求检查一下。
如果您以前有用过Dev C++之类也采用mingw32的IDE，那您最好先卸载了它们。如果您不懂什么叫mingw32,那估计你的机器就是没能安装过吧。那这一步跳过。
2.13 开始安装
双击下载的文件，就可以开始完装了，主要就两个注意点：
第一、选择"Full/完整"安装，免得一些插件没有被安装上。
第二、安装目录最好不要带有空格或汉字。
这一点并不是Code::Blocks的限制，而是因为mingw32里的一些命令行工具，似乎对长目录或带空格的目录支持有点小问题，我估计汉字目录也会出问题，但没试过。一句话，就装在根目录下的X:\CodeBlocks即可。比如我是安装在E:\CodeBlocks下。
2.2 升级Code::Blocks到最新svn版
Code::Blocks是开源的软件，它们源代码管理采用subversion管理，因此它的编译版本就直接采用svn的版本了。
code::blocks的网站看不去不怎么更新，其实程序的主要都在它的BBS（http://forums.codeblocks.org/）的nightly builds子论坛中更新。
2.2.1 下载升级文件，并覆盖原有文件
这里给出同样给出截至今天（北京时间2008年7月20日半夜3点）的最新升级包下载地址：
说明：
1、也许英文不是很好的朋友会觉得英文界面可能会用起来不方便，不过现在网上已经有朋友推出了中文的语言包。
下载地址：http://www.d2school.com/co...
2、Code::Blocks完整安装教程：http://www.d2school.com/co...
3、对于需要调试的朋友要注意，你的projects应该放在全英文的目录中才可以正常的使用调试功能。
下载的是.7zip的文件，可以用WinRAR或开源7zip软件解压全部文件，覆盖原目录下的文件，比如，我需要把它们解压:E:\CodeBlocks\ 目录下。
要持续跟踪最新版本，请关注本网站，或者直接到前述官方论坛查看。
2.2.2 试运行
双击桌面上的Code::Blocks启动图标――如果没有，那就到开始菜单里找找。启动时，能看到一个启动界面，右
下若有显示"svn 5142",那就说明安装及升级成功了。
当然，你也可以在启动完成后，像其他软件一样，到"Help"菜单下找"About"查看详细版本信息。
现在Code::Blocks还是英文界面的，接下来我们谈谈如何安装它的语言包。
2.3 使用本地语言包
首先，请在 X:\CodeBlocks\share\CodeBlocks\ 建立一个子文件夹：locale，注意 locale 全为小写字母。
我对简体汉字的语言包做了较大改进，不过仍然没改完，另外，一些插件在当前版本本来就无法汉化的，所以还有一部分内容是英语的。繁体部分我没有改动。
d2school版Code::Blocks语言包下载。
下载后，请解压到前述的locale目录下，则locale目录下，应出现zh_CN和zh_TW两个子目录。
重新启动Code::Blocks，点击主菜单的"Settings"，选择 "Enviornment"。出现的对话框中，左边选中"View"，右边打勾"Internationalization (needs restart)"，并在后面的复合框中选中"Chinese (Simplified)"。确认退出本对话框。
重启Code::Blocks。再看到的应该是中文简体界面了。
2.4 基本配置 Code::Blocks
一款编程用的IDE，一定要不断根据自己的需要进行配置，才会变得好用起来。不过本文仅仅讲那些必选项。也就是如果没配置好，这个Code::Blocks就干不了活的选项。有关其它的选项，因为太多，我不可能现在就开始写，以后我会慢慢整理一些放在本站。需要的人，请多关注www.d2school.com。主要会是一些常用的快捷键等配置，给不熟悉的人带个头，最终还是靠自己去配置。
2.41 配置g++编译器及调试器
请大家首先到 X:\CodeBlocks\MinGW\bin下，检查一下有没有以下文件：
mingw32-gcc.exe 这是C的编译器。
mingw32-g++.exe 这是C＋＋的编译器，同是地DLL（动态库）的连接器。
ar.exe 这是静态库的连接器。
gdb.exe 这里调试器。
windres.exe windows下资源文件编译器。
mingw32-make.exe 制作程序。
都没有问题，请点击c::b主菜单"设置"（汉化前的"Settings"），这次选中"编译器和调试器设置..."。，出现的对话框中，右边选中"全局编译器设置"，然后对照下图，检查左边配置是否正确无误：
现在我们就可以拿Code::Blocks来写课程里的很多C++代码了。
对于Linux的使用者，由于GCC原生于Linux, 所以只需下载Code::Blocks网站的.tar.gz即可。Code::Blocks对Debian系提供了更好的支援。
[Code::Bolcks在Linux下运行]
Code::Bolcks在Linux下运行
Setup of GTK and dev-c++ in Windows(2009)
GTK and Dev-C++的Windows移植(2009)
经过几天的摸索（n次的install/ininstall），终于搞定了gtk+ and dev-c++在windows平台上的安装配置。
网上google来的安装步骤基本是基于2004版的gtk，按照那些攻略或许有用。
下面是一些最新安装步骤和注意事项：
1.download gtk+安装包：http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.14/gtk+-bundle_2.14.7-20090119_win32.zip
2.download dev-c++安装包http://downloads.sourceforge.net/dev-cpp/devcpp-4.9.9.2_setup.exe?use_mirror=nchc
3.gtk解压缩到G:/devtool/dev-cpp(这个是我电脑安装目录，请参考之)
4.dev-c++安装到G:/devtool/dev-cpp(这个是我电脑安装目录，请参考之)（可以或略下面的5、6步骤）
5.运行dev-c++ and create a new gtk project。Codes flowwing：
#include <gtk/gtk.h>
int main( int argc,
char *argv[] )
{
GtkWidget *window;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);
gtk_main ();
return 0;
}
6.compile and find conpile error：1 G:\Devtool\Dev-CPP\Test\Untitled1.c gtk/gtk.h: No such file or directory. ；
7.配置环境变量I（setx请参考：http://guan-qiao.blogspot.com/2009/03/windossetxexe.html）：
setx path "%path%";G:/devtool/dev-c++
8.首先在Windows 下執行Command Mode:
pkg-config --cflagsgtk+-2.0
-mms-bitfields -IG:/devtool/dev-cpp/include/gtk-2.0 -IG:/devtool/dev-cpp/lib/gtk-2.0/include -IG:/devtool/dev-cpp/include/atk-1.0 -IG:/devtool/dev-cpp/include/cairo -IG:/devtool/dev-cpp/include/pango-1.0 -IG:/devtool/dev-cpp/include/glib-2.0 -IG:/devtool/dev-cpp/lib/glib-2.0/include -IG:/devtool/dev-cpp/include/libpng12
pkg-config --libs gtk+-2.0
-LG:/Devtool/Dev-C++/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgio-2.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl
9.配置环境变量II
// setx path "%include%";（上面步骤8中结果的所有路径）
//G:/devtool/dev-cpp/include/gtk-2.0;G:/devtool/dev-cpp/lib/gtk-2.0/include;G:/devtool/dev-cpp/include/atk-1.0;G:/devtool/dev-//cpp/include/cairo;G:/devtool/dev-cpp/include/pango-1.0;G:/devtool/dev-cpp/include/glib-2.0;G:/devtool/dev-//cpp/lib/glib-2.0/include;G:/devtool/dev-cpp/include/libpng12
//setx GTK_BASEPATH g:\Devtool\dev-cpp -m
//setx PKG_CONFIG_PATH=G:\Devtool\dev-cpp\lib\pkgconfig -m
//Dev Cpp 的 undefined reference to `__cpu_features_init'错误的解决
setx LIBRARY_PATH： G:\devtool\Dev-Cpp\lib;G:\devtool\dev-Cpp\mingw32\lib -m
Setx C_INCLUDE_PATH：G:\devtool\Dev-Cpp\include -m
10.restet dev-c++
11.hint：glade
经过几天的摸索（n次的install/ininstall），终于搞定了gtk+ and dev-c++在windows平台上的安装配置。
网上google来的安装步骤基本是基于2004版的gtk，按照那些攻略或许有用。
下面是一些最新安装步骤和注意事项：
1.download gtk+安装包：http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.14/gtk+-bundle_2.14.7-20090119_win32.zip
2.download dev-c++安装包http://downloads.sourceforge.net/dev-cpp/devcpp-4.9.9.2_setup.exe?use_mirror=nchc
3.gtk解压缩到G:/devtool/dev-cpp(这个是我电脑安装目录，请参考之)
4.dev-c++安装到G:/devtool/dev-cpp(这个是我电脑安装目录，请参考之)（可以或略下面的5、6步骤）
5.运行dev-c++ and create a new gtk project。Codes flowwing：
#include <gtk/gtk.h>
int main( int argc,
char *argv[] )
{
GtkWidget *window;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);
gtk_main ();
return 0;
}
6.compile and find conpile error：1 G:\Devtool\Dev-CPP\Test\Untitled1.c gtk/gtk.h: No such file or directory. ；
7.配置环境变量I（setx请参考：http://guan-qiao.blogspot.com/2009/03/windossetxexe.html）：
setx path "%path%";G:/devtool/dev-c++
8.首先在Windows 下執行Command Mode:
pkg-config --cflagsgtk+-2.0
-mms-bitfields -IG:/devtool/dev-cpp/include/gtk-2.0 -IG:/devtool/dev-cpp/lib/gtk-2.0/include -IG:/devtool/dev-cpp/include/atk-1.0 -IG:/devtool/dev-cpp/include/cairo -IG:/devtool/dev-cpp/include/pango-1.0 -IG:/devtool/dev-cpp/include/glib-2.0 -IG:/devtool/dev-cpp/lib/glib-2.0/include -IG:/devtool/dev-cpp/include/libpng12
pkg-config --libs gtk+-2.0
-LG:/Devtool/Dev-C++/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgio-2.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl
9.配置环境变量II
// setx path "%include%";（上面步骤8中结果的所有路径）
//G:/devtool/dev-cpp/include/gtk-2.0;G:/devtool/dev-cpp/lib/gtk-2.0/include;G:/devtool/dev-cpp/include/atk-1.0;G:/devtool/dev-//cpp/include/cairo;G:/devtool/dev-cpp/include/pango-1.0;G:/devtool/dev-cpp/include/glib-2.0;G:/devtool/dev-//cpp/lib/glib-2.0/include;G:/devtool/dev-cpp/include/libpng12
//setx GTK_BASEPATH g:\Devtool\dev-cpp -m
//setx PKG_CONFIG_PATH=G:\Devtool\dev-cpp\lib\pkgconfig -m
//Dev Cpp 的 undefined reference to `__cpu_features_init'错误的解决
setx LIBRARY_PATH： G:\devtool\Dev-Cpp\lib;G:\devtool\dev-Cpp\mingw32\lib -m
Setx C_INCLUDE_PATH：G:\devtool\Dev-Cpp\include -m
10.restet dev-c++
11.hint：glade
订阅：
博文 (Atom)