autotools精简（以webkit嵌入式浏览器移植为例）

本文简要说明了在嵌入式环境下如何精减GNU autotools(主要涵盖 autoconf、automake、libtool等)系统，以适应不同平台的编译需求。
一、简要介绍GNU autotools的历史渊源
GNU autotools的形成主要有两个历史渊源：先阐述一个碎片化的概念：unix自诞生之日起，就形成了大量的变种和分支，后来又出现了的大量的类unix系统（包括后起之秀linux），以及各种发行版。不同系统提供的头文件和库都有不少差异，这就给软件的发行带来了相当大的难度，发行一个软件必须测试所有的目标系统。这称之为unix的碎片化。
1）为解决碎片化的问题，autoconf可以通过提供测试项来测试目标系统的库和文件是否满足软件编译和运行的需求，若无法满足则报错（历史上出现过多种类似系统，有交互式的有非交互式的）。libtool也是同样的目的，不同的是，它的目标是提供和使用一致性的动态库。
2）自从Stuart Feldman 1977年在bell lab中制作了make工具（因此获得acm软件系统奖），make的使用越来越广泛，但撰写makefile（特别是为大型项目）尤其头痛。automake就为此而生。
二、autotools的框架
要学习autotools的知识，需要bash shell、GNU m4(老古董，宏扩展语言，缅怀Dennis Ritchie先生，后期会再撰文介绍)、make等的基础知识。
下述框图摘自GNU autoconf manual:
1）如果你只使用autoconf系统发布软件
    your source files --> [autoscan*] --> [configure.scan] --> configure.ac
     
     configure.ac --.
                    |   .------> autoconf* -----> configure
     [aclocal.m4] --+---+
                    |   `-----> [autoheader*] --> [config.h.in]
     [acsite.m4] ---'
     
     Makefile.in
2）如果你采用了automake，下述的操作也需要被执行：
     [acinclude.m4] --.
                      |
     [local macros] --+--> aclocal* --> aclocal.m4
                      |
     configure.ac ----'
     
     configure.ac --.
                    +--> automake* --> Makefile.in
     Makefile.am ---'
3）编译部署软件包所采用的操作：
                            .-------------> [config.cache]
     configure* ------------+-------------> config.log
                            |
     [config.h.in] -.       v            .-> [config.h] -.
                    +--> config.status* -+               +--> make*
     Makefile.in ---'                    `-> Makefile ---'


个人简单概括一下,使用的工具基本按如下先后次序：autoscan,aclocal,automake,autoconf,autoheader | configure make;有个简化版的工具autoreconf可以组合上述auto工具生成configure文件。
autotools主要是使用bash shell和m4构建，运行上述工具需bash和m4两种语言解释器。
上述面向开发者的源文件只有两种：configure.ac GNUmakefile.am(makefile.am)，是不是相当简单，呵呵
libtool的宏扩展内嵌包含在configure.ac和GNUmakefile.am中。
三、回归本文正题，精减autotools主要是精减掉libtools、去掉恼人的congigure test以及pkg-config（非GNU autotools工具，下文尽量不提）
例子以webkit移植到嵌入式环境为例说明。
先说一下精减autotools的理由：
1）往往大家在交叉编译开源库时，configure一下错误百出，好不容易把依赖库编好，还是不成。里面主要是libtool和pkg-config作祟，不信的话，make V=1一下，看到一串/usr/include(系统头文件)，还看到一串/usr/lib(系统库文件)。why,libtool和pkg-config生来就不是为交叉编译使用的，也可以说是不完备，他们记录信息的la、pc文件里面往往错误的指向了系统。往往还会生成错误的编译汇编指令导致无法编译通过。
2）假设把代码迁移到另一台服务器，还得重新部署依赖环境，会让一般人受不了。
3）再假如迁移到另一个平台比如说arm、mips，也需要重新部署头文件、库之类的。
理由说完了，下面要做的就是按部就班的解决问题就可以了，似乎剩下的就是粘贴代码了，代码见附件。
以libtool为例简要介绍下去除工作，其他工作请参考代码。
在congifure.ac文件中去除libtool的初始化工作，AC_PROG_LIBTOOL其实就是个m4宏扩展
  83 
  84 # initialize webkit options
  85 WEBKIT_INIT
  86 #AC_DISABLE_STATIC
  87 #AC_LIBTOOL_WIN32_DLL  ljc
  88 #AC_PROG_LIBTOOL ljc  去除libtool的初始化 
  89 AC_PROG_RANLIB
  90 # use dolt to speedup the build
  91 DOLT
在GNUmakefile.am中，以./Source/JavaScriptCore/GNUmakefile.am为例，下为diff -u的输出，-为修改之后的，+为修改之前的
 include $(srcdir)/Source/JavaScriptCore/GNUmakefile.list.am
 
-lib_LIBRARIES += \
-       libjavascriptcoregtk-@WEBKITGTK_API_MAJOR_VERSION@.@[email protected]
+lib_LTLIBRARIES += \
+       libjavascriptcoregtk-@WEBKITGTK_API_MAJOR_VERSION@.@[email protected]
 
 # We are going to make everything public for now. When
 # https://bugs.webkit.org/show_bug.cgi?id=27551 is fixed we'll able to
 # simply rely on the usual symbol visibility flags.
-#libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_a_LDFLAGS = \
-#      -version-info @LIBWEBKITGTK_VERSION@ \
-#      $(no_undefined)       #ljc
+libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_la_LDFLAGS = \
+       -version-info @LIBWEBKITGTK_VERSION@ \
+       $(no_undefined)
 
-nodist_EXTRA_libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_a_SOURCES = \
+nodist_EXTRA_libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_la_SOURCES = \
        $(javascriptcore_built_nosources)
 
-nodist_libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_a_SOURCES = \
+nodist_libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_la_SOURCES = \
        $(javascriptcore_built_sources)
 
-libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_adir = $(libwebkitgtkincludedir)/JavaScriptCore
-libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_a_HEADERS = $(javascriptcore_h_api)
+libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_ladir = $(libwebkitgtkincludedir)/JavaScriptCore
+libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_la_HEADERS = $(javascriptcore_h_api)
 
-libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_a_SOURCES = \
+libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_la_SOURCES = \
        $(javascriptcore_sources)
        
建议在做诸如此类的一批改动时，可以采用sed或者awk来处理，减小工作量。至于autoconf中的宏是啥意思，automake中 Canonicalization name、nodist前缀、SOURCES或者HEADERS后缀等，可以参考相应工具手册，后续若有时间会写篇科普性的文章介绍这些东东。






http://www.gnu.org/software/autoconf/manual/autoconf.html
http://www.gnu.org/software/automake/manual/automake.html
http://www.gnu.org/copyleft/fdl.html


附件WebKit-r103151.build.tar.gz 为修改后的文件（可能不太完备，但基本可用），遵循webkit源码版权

附件WebKit-r103151.orig.build.tar.gz为webkit的原始源码

附件暂时不知如何上传，若急需，可留邮件地址