用autoconf和automake生成makefile

lautoconf 的輸入檔案是 configure.in

lautomake的輸入檔案是 Makefile.am

1.用autoscan掃描原始碼目錄，為你生成configure.scan模板。

2.把configure.scan改名為configure.in

3.修改configure.in

1.AC_INIT(ShowServer, 1.0,[email protected]) 這個巨集是必須的。

2.AC_OUTPUT(Makefile ShowServer/Makefile TestClient/Makefile)

3.指定配置標頭檔案：AC_CONFIG_HEADER([config.h])這個由 autoheader產生

1.產生的標頭檔案必須被 .c或 .cpp檔案用 #include <config.h>包含。這些巨集才能應用到C編譯時。

2.用AC_DEFINE定義需要的巨集。

4.啟用 automake：AM_INIT_AUTOMAKE(ShowServer, 1.0)

5.檢查編譯器

1.AC_PROG_CXX此巨集用於檢查系統是否有g++編譯器。其它的巨集請看autoconf手冊

6.變數：

1.變數： CFLAGS

為C編譯器提供的除錯和優化選項。如果在執行configure時，沒有在環境中設定它，就在你呼叫AC_PROG_CC的時候設定它的預設值（如果你沒有呼叫AC_PROG_CC，它就為空）。 configure在編譯程式以測試C的特徵時，使用本變數。

2.變數： CPPFLAGS

為C前處理器和編譯器提供標頭檔案搜尋目錄選項（`-Idir'）以及其他各種選項。如果在執行 configure時，在環境中沒有設定本變數，預設值就是空。configure在編譯或者預處理程式以測試C的特徵時，使用本變數。

3.變數： CXXFLAGS

為C++編譯器提供的除錯和優化選項。如果在執行configure

4.變數： FFLAGS

為Fortran 77編譯器提供的除錯和優化選項。如果在執行configure時，在環境中沒有設定本變數，那麼它的預設值就在你呼叫AC_PROG_F77時被設定（如果你沒有呼叫AC_PROG_F77，它就為空）。 configure在編譯程式以測試Fortran 77的特徵時，使用本變數。

5.變數： DEFS

傳遞給C編譯器的`-D'選項。如果呼叫了AC_CONFIG_HEADER，configure就用 `-DHAVE_CONFIG_H'代替`@[email protected]'（參見配置頭文件）。在configure進行它的測試時，本變數沒有被定義，只有在建立輸出檔案時候才定義。關於如何檢查從前的測試結果，請參見。

6.變數： LDFLAGS

為聯結器提供的Stripping（`-s'）選項和其他各種選項。如果在執行configure時，在環境中沒有設定本變數，它的預設值就是空。 configure在連線程式以測試C的特徵時使用本變數。

7.變數： LIBS

傳遞給聯結器的`-l'和`-L'選項。

這裡可以用環境變數。例如：ACE庫存放在環境變數ACE_LIB中，則可以這樣指定：

LIBS= -L$ACE_LIB

8.檢查依賴庫：

1.configure檢查時的路徑為，系統預設庫路徑，再就是 LIBS中用 –L指定的路徑。詳見變數中的LIBS

2.AC_CHECK_LIB([pthread], [pthread_create], , exit 1)

3.AC_HAVE_LIBRARY([ACE], , exit 1)

4.AC_HAVE_LIBRARY([Cfg], , exit 1)

9.其它檢查：

a)詳見AUTOCONF文件

b)2.建立一個a.sh檔案：

echo autoheader
autoheader
echo aclocal
aclocal
echo autoconf
autoconf

#產生ltmain.sh

#libtoolize --automake --copy --debug --force
echo automake
automake --add-missing
echo ./configure
./configure

c)執行a.sh就能產生Makefile了

7.從命令列獲取引數

AC_ARG_ENABLE

opt_debug=yes

AC_ARG_ENABLE(debug, AC_HELP_STRING([--enable-debug], [enable debug [[default=yes]]]), opt_debug=$enableval)

if test $opt_debug = "yes"; then

#AC_DEFINE(_DEBUG)

CXXFLAGS="-D_DEBUG "

fi

[email protected]:~#./configure –help

Optional Features:

--disable-FEATUREdo not include FEATURE (same as --enable-FEATURE=no)

--enable-FEATURE[=ARG]include FEATURE [ARG=yes]

--disable-dependency-trackingspeeds up one-time build

--enable-dependency-trackingdo not reject slow dependency extractors

--enable-debugenable debug [default=yes]

8.automake 支援條件

 AM_CONDITIONAL (conditional, condition)

AM_CONDITIONAL (conditional, condition) [Macro]
The conditional name, conditional, should be a simple string starting with a letter
and containing only letters, digits, and underscores. It must be different from ‘TRUE’
and ‘FALSE’ that are reserved by Automake.
The shell condition (suitable for use in a shell if statement) is evaluated when
configure is run. Note that you must arrange for every AM_CONDITIONAL to be
invoked every time configure is run. If AM_CONDITIONAL is run conditionally (e.g.,
in a shell if statement), then the result will confuse automake.
Conditionals typically depend upon options that the user provides to the configure
script. Here is an example of how to write a conditional that is true if the user uses the
‘--enable-debug’ option.
AC_ARG_ENABLE([debug],
[ --enable-debug Turn on debugging],
[case "${enableval}" in
yes) debug=true ;;
no) debug=false ;;
*) AC_MSG_ERROR([bad value ${enableval} for --enable-debug]) ;;
esac],[debug=false])
AM_CONDITIONAL([DEBUG], [test x$debug = xtrue])
Here is an example of how to use that conditional in ‘Makefile.am’:
if DEBUG
DBG = debug
else
DBG =
endif
noinst_PROGRAMS = $(DBG)

9.示例：

autoconf檔案：

#                                              -*- Autoconf -*-

# Process this file with autoconf to produce a configure script.

 

AC_PREREQ(2.59)

AC_INIT(ShowServer, 1.0, [email protected])

AC_CONFIG_SRCDIR([.])

AC_CONFIG_HEADER([config.h])

AM_INIT_AUTOMAKE(ShowServer, 1.0)

 

# Checks for programs.

AC_PROG_CXX

 

#從命令列中檢查引數，根據引數做相應的定義

opt_debug=yes
AC_ARG_ENABLE(debug, AC_HELP_STRING([--enable-debug], [enable debug [[default=yes]]]), opt_debug=$enableval)
if test $opt_debug = "yes"; then   #這個不能用 if [ $opt_debug = "yes" ] then,因為 []在autoconf中有其它含意。
 #AC_DEFINE(_DEBUG)
 CXXFLAGS="-D_DEBUG "
fi

 

CFLAGS=" -O2"

CXXFLAGS+=" -D_DEBUG -I$ACE_INCLUDE -I$LIB_PATH/include"  #標頭檔案目錄

LIBS="-L. -L$ACE_LIB " #包含ACE的庫的環境變數

 

# Checks for libraries.

AC_CHECK_LIB([pthread], [pthread_create], , exit 1)

AC_HAVE_LIBRARY([ACE], , exit 1) #在LIBS中指定的路徑中找，找到後，預設的操作是把ACE庫加到LIBS中。

 

# Checks for header files.

AC_HEADER_STDBOOL

AC_C_CONST

 

# Checks for typedefs, structures, and compiler characteristics.

 

# Checks for library functions.

 

 

AC_PROG_INSTALL

 

AC_OUTPUT(Makefile ShowServer/Makefile TestClient/Makefile)

注意：在指令碼中變數就只由$引用，不需要“（）”。

 Makefile.am

AUTOMAKE_OPTIONS = foreign

lib_LTLIBRARIES = libSxitCommunicate.la

libSxitCommunicate_la_CPPFLAGS = /
  -DACE_BUILD_SVC_DLL

libSxitCommunicate_la_SOURCES = /
  SxitCommunicate.cpp /
  SxitComm.cpp /
  CommunicateImpt.cpp/
  ImptCommunicateRemote.cpp /
  ImptCommunicateLocal.cpp /
  NetIdManage.cpp /
  SxitPacketHandler.cpp

bin_PROGRAMS:生成執行檔案

lib_LTLIBRARIES：生成庫，根據庫字尾名來確定生成什麼庫（安裝）

noinst_LIBRARIES：生成庫（不安裝）

編譯庫：

看GUN Automake手冊中的相應段（8.2Building a library）。這裡只說明靜態庫，動態庫的命名方式。

物件檔案命名為：lib***.o

靜態庫命名為 lib***.a

動態庫的命名為 lib***.so

libtool工具庫命名為 lib***.la

lib***.la 是a libtool library file，它是一個文字檔案，用於libtool

lib***.lo是a libtool object file，它是一個文字檔案，用於libtool

Automake一般在當前目錄下會產生一個 .libs ，這個目錄中包含生成的物件檔案和庫檔案。

編譯選項：

      -static：生成靜態庫
           On systems that support dynamic linking, this prevents linking with the
           shared libraries.  On other systems, this option has no effect.

       -shared：生成動態庫
           Produce a shared object which can then be linked with other objects to
           form an executable.  Not all systems support this option.  For pre-
           dictable results, you must also specify the same set of options that
           were used to generate code (-fpic, -fPIC, or model suboptions) when you
           specify this option.[1]

       -shared-libgcc
       -static-libgcc
           On systems that provide libgcc as a shared library, these options force
           the use of either the shared or static version respectively.  If no
           shared version of libgcc was built when the compiler was configured,
           these options have no effect.

           There are several situations in which an application should use the
           shared libgcc instead of the static version.  The most common of these
           is when the application wishes to throw and catch exceptions across dif-
           ferent shared libraries.  In that case, each of the libraries as well as
           the application itself should use the shared libgcc.

           Therefore, the G++ and GCJ drivers automatically add -shared-libgcc
           whenever you build a shared library or a main executable, because C++
           and Java programs typically use exceptions, so this is the right thing
           to do.

           If, instead, you use the GCC driver to create shared libraries, you may
           find that they will not always be linked with the shared libgcc.  If GCC
           finds, at its configuration time, that you have a non-GNU linker or a
           GNU linker that does not support option --eh-frame-hdr, it will link the
           shared version of libgcc into shared libraries by default.  Otherwise,
           it will take advantage of the linker and optimize away the linking with
           the shared version of libgcc, linking with the static version of libgcc
           by default.  This allows exceptions to propagate through such shared
           libraries, without incurring relocation costs at library load time.

           However, if a library or main executable is supposed to throw or catch
           exceptions, you must link it using the G++ or GCJ driver, as appropriate
           for the languages used in the program, or using the option
           -shared-libgcc, such that it is linked with the shared libgcc.

3.1 編譯安裝

編譯和安裝的規則是繫結在一起的，通過同一條語句同時指定了編譯和安裝的處理方式，具體的格式為：安裝目錄_編譯型別=編譯目標

3.1.1【安裝目錄】

例如：bin_PROGRAMS = hello subdir/goodbye，其中安裝目錄是bin，編譯型別是PROGRAMS，編譯目標是兩個程式hello, goodbye.

常用預設的安裝目錄如下

除了常用的預設目錄外，有時候我們還需要自定義目錄，例如日誌目錄log，配置目錄config，這種目錄可以通過自定義目錄方式定義，然後按照預設目錄的使用方式使用即可。例如：自定義config目錄的方式如下：

configdir=${prefix}/log  => 定義一個自定義的目錄名稱config,注意dir字尾是固定的

config_DATA=config/test.ini  => 使用自定義的目錄config，必須要有這句，否則目錄不會建立, =號後面如果有對應的檔案，安裝時會將對應的檔案拷貝到config目錄下。

3.1.2【編譯型別】

常見編譯型別如下，沒有自定義編譯型別

3.1.3【編譯目標】

編譯目標其實就是編譯型別對應的具體檔案，其中需要make生成的檔案主要有如下幾個：可執行程式_PROGRAMS，普通庫檔案_LIBRARIES，libtool庫檔案_LTLIBRARIES,其它型別對應的編譯目標不需要編譯，原始檔就是目標檔案。

Ø  標準的編譯配置

如果你熟悉gcc的編譯命令寫法，那麼Automake的Makefile.am編譯過程就很好寫了。因為Automake只是將寫在一行gcc命令裡的各個不同部分的資訊分開定義而已。我們來看具體是如何定義的：

_SOURCES：對應gcc命令中的原始碼檔案

_LIBADD：編譯連結庫時需要連結的其它庫，對應gcc命令中的*.a, *.so等檔案

_LDADD：編譯連結程式時需要連結的其他庫，對應gcc命令中的*.a, *.so等檔案

_LDFLAGS：連結選項，對應gcc命令中的-L, -l, -shared, -fpic等選項

_LIBTOOLFLAGS：libtool編譯時的選項

**FLAGS(例如_CFLAGS/_CXXFLAGS)：編譯選項，對應gcc命令中的-O2, -g, -I等選項

_DEPENDENCIES：編譯連結庫時需要的依賴條件，可以是檔案，也可以是規則，在規則中可以定義自定義指令碼

舉例如下：

Ø  如何編譯可執行程式

對於大型專案來說，程式碼基本上都是分目錄存放的，如果是直接寫makefile檔案，一般都是將所有原始檔首先編譯成*.o的檔案，再連結成最終的二進位制檔案。但在Automake裡面這樣是行不通的，因為你只要仔細看編譯型別表格就會發現，並沒有一種編譯型別能夠編譯*.o檔案，無法像常規makefile那樣來編寫，所以就需要採取一些技巧。

其實這個技巧也很簡單：將非main函式所在目錄的檔案編譯成靜態連結庫，然後採用連結靜態庫的方式編譯可執行程式。

樣例如下：

=================根目錄Makefile.am======================

=================tool目錄Makefile.am======================

===============common目錄Makefile.am======================

==============worker目錄Makefile.am============================

Ø  如何編譯靜態庫

Automake天然支援編譯靜態庫，只需要將編譯型別指定為_LIBRARIES即可。

Ø  如何編譯動態庫

需要注意的是：_LIBRARIES只支援靜態庫(即*.a檔案),而不支援編譯動態庫(*.so)檔案，要編譯動態連結庫,需要使用_PROGRAMS。除此之外，還需要採用自定義目錄的方式避開Automake的兩個隱含的限制：

1)      如果使用bin_PROGRAMS, 則庫檔案會安裝到bin目錄下，這個不符合我們對動態庫的要求；

2)      automake不允許用lib_ PROGRAMS

下面假設將utils編譯成so，採用自定義目錄的方式，修改Makefile.am如下：

Ø  如何編譯libtool庫

對於跨平臺可移植的庫來說，推薦使用libtool編譯，而且Automake內建了libtool的支援，只需要將編譯型別修改為_LTLIBRARIES即可。

需要注意的是：如果要使用libtool編譯，需要在configure.ac中新增LT_INIT巨集，同時註釋掉AC_PROG_RANLIB，因為使用了LT_INIT後，AC_PROG_RANLIB就沒有作用了。

編譯時自定義指令碼：

automake提供編譯時使用者自定義清理規則：

clean-local

3.2 打包

make dist  #只打包

或者

make distcheck      #打包並對打的包解壓進行編譯檢查，看是否出錯

Automake預設情況下會自動打包，自動打包包含如下內容：

1)      所有原始檔

2)      所有Makefile.am/Makefile.in檔案

3)      configure讀取的檔案

4)      Makefile.am’s (using include) 和configure.ac’ (using m4_include)包含的檔案

5)      預設的檔案，例如README, ChangeLog, NEWS, AUTHORS

如果除了這些預設的檔案外，你還想將其它檔案打包，有如下兩種方法：

(1)   粗粒度方式：通過EXTRA_DIST來指定，例如：

EXTRA_DIST=conf/config.ini  test/test.php  tools/initialize.sh

(2)   細粒度方式：在“安裝目錄_編譯型別=編譯目標”前新增dist(表示需要打包),或者nodist(不需要打包)，例如：

安裝時自定義指令碼：

automake提供兩個規則供使用者在完裝完後自定義指令碼：

install-exec-hook

install-data-hook

提供相應的反安裝自定義指令碼規則：

uninstall-hook

工具簡介

所必須的軟體：autoconf/automake/m4/perl/libtool（其中libtool非必須）。

autoconf是一個用於生成可以自動地配置軟體原始碼包，用以適應多種UNIX類系統的shell指令碼工具，其中autoconf需要用到 m4，便於生成指令碼。automake是一個從Makefile.am檔案自動生成Makefile.in的工具。為了生成Makefile.in，automake還需用到perl，由於automake建立的釋出完全遵循GNU標準，所以在建立中不需要perl。libtool是一款方便生成各種程式庫的工具。

目前automake支援三種目錄層次：flat、shallow和deep。

1) flat指的是所有檔案都位於同一個目錄中。

就是所有原始檔、標頭檔案以及其他庫檔案都位於當前目錄中，且沒有子目錄。Termutils就是這一類。

2) shallow指的是主要的原始碼都儲存在頂層目錄，其他各個部分則儲存在子目錄中。

就是主要原始檔在當前目錄中，而其它一些實現各部分功能的原始檔位於各自不同的目錄。automake本身就是這一類。

3) deep指的是所有原始碼都被儲存在子目錄中；頂層目錄主要包含配置資訊。

就是所有原始檔及自己寫的標頭檔案位於當前目錄的一個子目錄中，而當前目錄裡沒有任何原始檔。 GNU cpio和GNU tar就是這一類。

flat型別是最簡單的，deep型別是最複雜的。不難看出，我們的模擬需求正是基於第三類deep型，也就是說我們要做挑戰性的事情：)。注：我們的測試程式是基於多執行緒的簡單程式。

首先進入 project 目錄，在該目錄下執行一系列命令，建立和修改幾個檔案，就可以生成符合該平臺的Makefile檔案，操作過程如下：

1) 執行autoscan命令

2) 將configure.scan 檔案重新命名為configure.in，並修改configure.in檔案

3) 在project目錄下新建Makefile.am檔案，並在core和shell目錄下也新建makefile.am檔案

4) 在project目錄下新建NEWS、 README、 ChangeLog 、AUTHORS檔案

5) 將/usr/share/automake-1.X/目錄下的depcomp和complie檔案拷貝到本目錄下

6) 執行aclocal命令

7) 執行autoconf命令

8) 執行automake -a命令

9) 執行./confiugre指令碼

可以通過圖2看出產生Makefile的流程，如圖所示：

在linux下編譯c/c＋＋程式出錯：

顯示程式碼列印
 $ automake --add-missing  

 configure.in:18: required file `build/ltmain.sh' not found  

解決方案(libtoolize配置即可)：

顯示程式碼列印
 $libtoolize --version 

 -libtoolize (GNU libtool) 1.4.2  

 $libtoolize --automake --copy --debug --force