之前看过Alexandre Duret-Lutz的《Using GNU Autotools》，对于 autotools 的使用并
不陌生，但是总是觉得自己对于这些工具的理解非常的模糊，很多时候都只是停留在知其然
不知其所以然的层面。这是我为什么读《GNU Autoconf, Automake and Libtool》这本书的
原因。这本书是我无意间在 google 上漫游的时候搜索到的，这本书我只看了前面几个章节
，后面的内容过于索然无味，弃之。
autotool 的由来
autotool 主要包含三个工具，autoconf、automake、libtool。这些工具之所以会出现和
unix 的发展有很大的关系。unix发展初期因为授权问题出现了大量的版本，而这些版
本中提供的库函数各不相同，却又大同小异。想要编写在各个版本中都可移植的程序非常困
难。为了解决这个问题才出现了autoconf这一类的软件，它们的本质实际上是帮你探测不
同的系统的属性，也就是告诉你哪个功能有，哪个功能没有之类的。这一点让我想起
JavaScript发展初期的时候遇到的同样的问题，各种浏览器支持的特性各不相同，想要写一
个跨浏览器的脚本同样非常困难。这从一个侧面反映出一个标准的重要性。
autoconf 可以帮助你写出款平台编译的程序，而automake则主要是帮你更好的完成跨
平台编译这件事情。编译需要用到各种编译器命令，因为不想手动的执行这些命名出现了
Makefile，又因为不想手动的编写Makefile出现了automake这类的工具，它让你可以
只提供源文件的名称便替你生成 Makefile，这也着实省下不少的麻烦。
程序库的发展过程中首先出现的是静态库，实际上只是.o的打包而已。后来出现了更高级
的动态库，可惜的是和之前一样，这些动态库在不同的系统上实现是不一样的，为了能够跨
平台的生成这些程序库，也就有了libtool这类的工具。
前面的介绍中，我使用的词语都是这类的，因为这种工具其实上出现过很多种，只是到了
最后慢慢的统一成了目前我们看到的这几个，他们最终合起来被称为autotools。
做一个实用主义者
不要尝试去写一个可以运行在一切平台的configure脚本，实用为主，如果你只需要在
Linux上运行，又何苦去测试Windows才有的功能呢？
configure.in，configure.ac 结构
通常应该按照下面的顺序编程一个configure.ac文件：
- 引用 AC_INIT，AM_INIT_AUTOMAKE，AC_CONFIG_HEADER 等等
- 选项，比如：AC_ARG_ENABLE
- 程序检测，比如：AC_CHECK_PROG
- 库的检测
- 头文件检测
- typedefs 和 结构体的检测
- 函数的检测
- 输出：AC_OUTPUT