除了autoconf和automake，GNU的autotools工具包中还有一种工具，它就是libtool。顾名思义，libtool是一个关于库文件制作、安装和使用的工具，它屏蔽了各个平台在库制作、安装和使用方面的差异，为上层提供了统一的接口。你可以直接使用libtool创建静态或共享库，也可以将libtool与autoconf、automake结合在一起使用。第二种方式显然更具实际意义，也更为简单。

在一个使用autoconf和automake构建的编译环境中添加libtool的支持，只需改动几处即可：
首先，你需要在configure.in(或configure.ac)中添加AC_PROG_LIBTOOL宏(注意：去掉AC_PROC_RANLIB宏)。
其次，修改Makefile.am：
如果是建立库文件，则需将lib_LIBRARIES改为lib_LTLIBRARIES，同时将库的后缀名由.a改为.la，这将告诉automake采用libtool来创建相关库：
lib_LIBRARIES = libfoo.a => lib_LTLIBRARIES = libfoo.la
libfoo_a_SOURCES = libfoo.c => libfoo_la_sources = libfoo.c

如果是使用上面生成的库文件，则将可执行程序链接的库改为.la，如：
fooapp_SOURCES = fooapp.c
fooapp_LDADD = libfoo.la

更新完上述配置后，删除aclocal.m4，执行aclocal和autoreconf，此时如果你的系统中没有安装libtool的话，autoconf会提示"undefined macro AC_PROG_LIBTOOL"，安装libtool(sudo apt-get install libtool)后，错误提示消失。autoreconf会初始化libtool环境，并将libtool和ltmain.sh两个脚本拷贝到你的工程目录下。由于修改了Makefile.am，你还需要重新执行依次automake。

后面的操作大家就很熟悉了，configure -> make -> make install。libtool默认状态下会将静态库(.a)和共享库(.so)都生成出来，不过你可以通过configure命令行参数来控制这一切：
–disable-shared 不生成共享库
–disable-static 不生成静态库
–enable-shared 生成共享库
–enable-static 生成静态库

你同样可以在configure.in中控制创建的库的类型，比如，在configure.in中增加AC_DISABLE_SHARED宏就可以让libtool只创建静态库，而不生成共享库。

执行make install将库安装完后，你会发现在安装的lib目录下还保留有一份.la文件，通过该.la文件，我们可以继续通过libtool来使用这些库。当然你也可以完全略过.la而直接链接静态库(.a)和共享库(.so)。

今天尝试使用autoconf和automake重新构建一个遗留库的Build环境。之前改造的lcut的目录结构还是相对简单，改造时并未遇到什么难题，不过今天就没那么幸运了，我在头文件目录包含设置这个看似简单的环节上遇到了一些小麻烦。

这个库结构其实也没那么复杂，只是源文件和头文件不在一个目录下罢了：
testproj/
    – Makefile.am
    – configure.in
    – include/
        – xx.h
        – yy.h
    – module1
        – xx.c
        – Makefile.am
    – moudle2
        – yy.c
        – Makefile.am
   
开始也没多想，参照以前的经验一步一步生成configure脚本。执行configure脚本生成Makefile文件，敲入make。在进入module1目录后，提示编译xx.c文件失败，无法找到xx.h！看了一下gcc的编译选项，的确没有-I上层的include目录，只有"-I."和"-I.."。翻看了一下automake的manual，发现automake默认情况下是将config.h所在的目录当作-I的参数。我的configure.in中是这样设置的:AC_CONFIG_HEADERS([config.h])，怪不得无法正确设置目录呢！将该句改为AC_CONFIG_HEADERS([include/config.h])后，重新生成Makefile并执行make，这回gcc命令行上出现了"-I../include"的字样，编译也很是顺利。

不过就这样算了，似乎总觉不妥，config.h只有一个，但如果有多个include目录的情况下该如何设置头文件包含目录呢？带着这个问题我再次翻看了automake的手册。老天不负有心人^_^，手册里确有这方面的说明。

原来automake从autoconf里继承了很多编译时需要的变量，诸如CC, CFLAGS, CPPFLAGS, DEFS, LDFLAGS,LIBS等等。但automake也可自己设置一些编译时用到的变量，automake与Build相关的一些变量名字也都以AM_开头，诸如AM_CPPFLAGS(与CPPFLAGS对应)。在Makefile.am中设置头文件包含的方式至少有以下两种：

* 在顶层Makefile.am中设置全局变量
AM_CPPFLAGS = -I $(top_srcdir)/include1
export AM_CPPFLAGS
这样在编译子目录（如module1)时，该全局设置也会起作用，在gcc编译命令行中你会看到-I ../include1。

* 在子目录层Makefile.am中设置局部变量
AM_CPPFLAGS = -I $(top_srcdir)/include2
这里的设置仅仅影响该目录下源文件的编译，对于其他同级目录下的源文件不起作用。另外如果此时顶层的Makefile.am中依然有AM_CPPFLAGS的设置，那么子目录下的Makefile.am中的这些设置会覆盖掉顶层的定义，在gcc编译命令行中也只会看到-I include2而无-I include1。

除了在Makefile.am中手工显式设置外，也可在执行configure脚本的时候通过传入CPPFLAGS参数来设定包含头文件位置，如configure CPPFLAGS=-I./include3。注意"CPPFLAGS"、"="和后面的值之间不能有空格。在automake manual中也有这方面的说明：在命令行中这里的CPPFLAGS将被放到AM_CPPFLAGS后面并一起传给gcc。

对于automake中的其他Build相关的AM_XXFLAGS变量，其道理也是相同的，这里就不赘述了。