chap6-2-unix-make編譯維護工具

1后綴名說明.cC語言源代碼文件.C/.cc/.cxxC++源代碼文件.h程序所包含的頭文件.i已經(jīng)預處理過的C語言源代碼文件.ii已經(jīng)預處理過的C++源代碼文件.mObjective-C語言源代碼文件.s匯編語言源代碼文件.S經(jīng)過預編譯的匯編語言源代碼文件.a/.so編譯后的庫代碼.o編譯后的目標文件GNUC/C++編譯器的使用gcc通過擴展名來判斷文件的類型，從而確定用何種方式處理該文件2GNUC/C++編譯器的使用gcc編譯器選項和參數(shù)參數(shù)含義-o<file>Placetheoutputinto<file>-cCompileandassemble,butdonotlink-ggdbProducedebugginginformationforusebyGDB.-Othecompilertriestoreducecodesizeandexecutiontime,withoutperforminganyoptimizationsthattakeagreatdealofcom-pilationtime.-gProducedebugginginformationintheoperatingsystem'snativeformat.GDBcanworkwiththisdebugginginformation.-I<dir>Addthedirectorydirtothelistofdirectoriestobesearchedforheaderfiles.Directoriesnamedby-Iaresearchedbeforethe-L<dir>Searchthelibrarynamedlibrarywhenlinking3GNUC/C++編譯器的使用1、直接通過編譯生成目標代碼可執(zhí)行文件：$gcchello.c–ohello2、如果一個程序包含有多個源文件，則也可直接生成目標代碼：voidf1(){printf(“%s\n”,"function1");}voidf2(){printf("%s\n","function2");}main(){f1();f2();}$gccf1.cf2.cmain.c–omain4Linux上廣泛使用的C語言編譯器是GNUC編譯器，GNUC建立在自由軟件基金會的編程許可證的基礎上，可以自由發(fā)布。在Linux下，一個完整的C語言開發(fā)環(huán)境到少包括以下三個組成部分：函數(shù)庫glibc(在/usr/lib和/lib目錄中)編譯器gcc系統(tǒng)頭文件glibc_header(*.h)glibc是構成一個完整的C語言開發(fā)環(huán)境所必不可少的組成部分，也是Linux下C語言的主要函數(shù)庫。glibc_header中包含了系統(tǒng)編譯源代碼所需要的聲明文件,如果缺少系統(tǒng)頭文件，很多用到系統(tǒng)功能的C程序將無法編譯。(包含在/usr/include/及其子目錄中)5GNUC/C++函數(shù)庫定義：是一些預先編譯好的函數(shù)的集合，那些函數(shù)都是按照可再使用的原則編寫的。它們通常是一組相互關聯(lián)的用來完成某項常見工作的函數(shù)構成（比如c庫里面的標準輸入輸出函數(shù)、時間函數(shù)和數(shù)學函數(shù)等）。函數(shù)庫中的函數(shù)可以通過連接程序與應用程序進行連接，而不必在每次開發(fā)程序時都對這些通用的函數(shù)進行編譯。不同類型的應用程序將會使用不同的函數(shù)庫。如數(shù)學應用將使用數(shù)學庫libm(/usr/lib/libm.a,/usr/lib/libm.so)，標準的C庫libc(/usr/lib/libc.a,/usr/lib/libc.so)。注意：*.h只是對函數(shù)的聲明（declaration）,函數(shù)的定義是在具體的函數(shù)庫中6所有的程序都將使用標準的C函數(shù)庫libc，該庫中包含了內(nèi)存管理或輸入輸出操作的基本函數(shù)，這些庫都存放在/usr/lib或/lib這些系統(tǒng)公用的目錄中，系統(tǒng)中的任何用戶都可以利用這些庫。注：用戶可以自己定義自己的函數(shù)庫！庫可以有三種使用的形式：靜態(tài)庫(*.a)：代碼在編譯時就已連接到開發(fā)人員開發(fā)的應用程序中。靜態(tài)庫在程序編譯時會被連接到目標代碼中，程序運行時將不再需要該靜態(tài)庫共享庫(sharedobject,以*.so作為后綴)：只是在程序開始運行時才載入，在編譯時，只是簡單地指定需要使用的庫函數(shù)。動態(tài)庫：是共享庫的另一種變化形式，也是在程序運行時載入，使用的庫函數(shù)不是在程序運行開始，而是在程序中的語句需要使用該函數(shù)時才載入。類似于windowsOS中的DLL文件。7共享庫的生成方法動態(tài)庫可以在程序運行期間釋放動態(tài)庫所占用的內(nèi)存，騰出空間供其他程序使用。由于共享庫和動態(tài)庫并沒有在程序中包括庫函數(shù)的內(nèi)容，只是包含了對庫函數(shù)的引用，因此代碼的規(guī)模比較小。生成用戶共享庫的方法：gcctest1.ctest2.ctest3.c-fPIC-shared-olibtest.so使用自定義的庫進行編譯、連接gcctest.c-L.libtest.so-otest8靜態(tài)庫的生成方法靜態(tài)庫的生成方法：Step1:編譯而不連接$gcctest1.c-c-otest1.o$gcctest2.c-c-otest2.o$gcctest3.c-c-otest3.oStep2:生成ar命令生成靜態(tài)庫$arrcslibtest.atest1.otest2.otest3.oStep3:使用靜態(tài)庫編譯和連接，生成可執(zhí)行文件gcctest.c-L.libtest.a-otest9系統(tǒng)中可用的庫都存放在/usr/lib和/lib目錄中。庫文件名由前綴lib和庫名以及后綴組成。根據(jù)庫的類型不同，后綴名也不一樣。共享庫名的格式：庫的名稱.so.主版本號.次版本號靜態(tài)庫名的格式：庫的名稱.a例如：libm.so.5 數(shù)學共享庫的標識字符為m，版本號為5libm.a 靜態(tài)數(shù)字庫libc.a為標準C庫10函數(shù)庫存放的標準目錄：/lib 系統(tǒng)必備共享庫/usr/lib 標準共享庫和靜態(tài)庫/usr/i486-linux-libc5/lib libc5兼容性函數(shù)庫/usr/X11R6/lib X11R6的函數(shù)庫/usr/local/lib 本地函數(shù)庫11頭文件存放的目錄：/usr/include 系統(tǒng)頭文件 /usr/local/include 本地頭文件共享庫及相關配置文件在/etc目錄中，其中：ld.so.conf 包含共享庫的搜索位置ldconfig 共享庫管理工具，一般在更新了共享庫之后要運行該命令ldd 可查看可執(zhí)行文件所使用的共享庫e.g.#lddtest,查看test文件的共享庫依賴make工具

在開發(fā)大型軟件時，往往要把整個系統(tǒng)劃分成若干個子系統(tǒng)，然后再把子系統(tǒng)劃分幾個能獨立工作的模塊，使得軟件系統(tǒng)模塊化。這樣在對系統(tǒng)進行編譯時就要按模塊進行編譯。

當模塊變更時，采用手工編譯方法可能漏掉一些已經(jīng)修改過或受影響的模塊，不能保證生成的可執(zhí)行文件使用最新的程序模塊。當程序的各模塊之間的調(diào)用關系比較復雜時，一個模塊的修改往往要引起許多目標文件的重新編譯與生成例如當一個程序由模塊main.c,x1.c,x2.c組成時，其編譯過程如下：make工具(2)$cc–cmain.c$cc–cx1.c$cc–cx2.c$cc–oprogmain.ox1.ox2.o在上例中，x1.c,x2.c或main.c中任一模塊的更改都將影響程序prog的生成。

基本功能：

自動實現(xiàn)模塊間的依賴關系,根據(jù)程序中模塊的修改情況，僅重新編譯修改模塊及其關聯(lián)模塊，連接所有目標代碼，以保證最終可執(zhí)行文件總是由組成它的模塊的最新版生成。make命令make命令是UNIX系統(tǒng)下開發(fā)大中型軟件時，常用的一個程序自動維護工具。make命令基本操作

在說明文件(makefile)中尋找目標文件

保證該目標文件所依賴的所有文件都存在且是最新的版本

在任一程序的修改晚于該目標文件生成時間的前提下創(chuàng)建目標文件make命令參數(shù)make命令的常用參數(shù)：-f-i-s-r-p-e-n

指定make的說明文件忽略調(diào)用命令返回的錯誤代碼執(zhí)行時不顯示所執(zhí)行的命令不使用內(nèi)部規(guī)則打印makefile中的宏及依賴信息不接收對shell環(huán)境變量賦值的宏定義非執(zhí)行方式makefile的概念：來自文件系統(tǒng)的文件名和最近一次的修改日期和時間將一些間隔連接起來的內(nèi)部規(guī)則makefile文件Makefile是一個描述文件，所描述的主要內(nèi)容是模塊間的依賴關系及在此依賴關系基礎上所采取的動作。Make命令在操作時就遵循這個文件所定義的規(guī)范。make命令使用的信息源：makefile是普通的文本文件，可以使用任何一種UNIX系統(tǒng)下的文本編輯器創(chuàng)建和修改makefile文件(2)makefile必須與它使用的源文件放在同一個目錄下機群系統(tǒng)并行程序調(diào)試環(huán)境DENNET19Makefile里有什么？Makefile里主要包含了五個東西：顯式規(guī)則：要生成的文件，文件的依賴文件，生成的命令

隱晦規(guī)則：自動推導目標文件和依賴文件名的關系變量定義：運行make時，變量都會被擴展到相應的引用位置上文件指示：(1)在一個Makefile中引用另一個Makefile，與c語言中的#include一樣，使用“includefoo.make”這種方式（如果是“-includefoo.make”，則表示忽略foo.make中的錯誤）；(2)根據(jù)某些情況指定Makefile中的有效部分，就像C語言中的預編譯#if一樣；(3)定義一個多行的命令注釋：#Makefile中的命令，必須要以[Tab]鍵開始

機群系統(tǒng)并行程序調(diào)試環(huán)境DENNET20Makefile的文件名

Makefile的一般命名規(guī)則為：常規(guī)命名順序：GNUmakefile〉makefile〉Makefile特定名稱：Makefile.linuxmake–fMake.linuxmake–fileMake.linuxMakefile最常用，一方面因為顯目，另一方面符合大多數(shù)人的習慣

機群系統(tǒng)并行程序調(diào)試環(huán)境DENNET21make的工作方式

讀入所有的Makefile；讀入被include的其它Makefile；初始化文件中的變量；推導隱晦規(guī)則，并分析所有規(guī)則；為所有的目標文件創(chuàng)建依賴關系鏈；根據(jù)依賴關系，決定哪些目標要重新生成；執(zhí)行生成命令。

makefile的編寫(2)注釋：可以在makefile的任意位置添加注釋注釋以#開始，以換行符結束包括行：把別的文件包括進makefile其格式為：#include“文件名”宏：定義格式為：macro-variable=value宏可以簡化makefile描述文件的書寫23規(guī)則的定義規(guī)則中的項目定義必須從最左邊開始，一個規(guī)則中的第二行以后的行必須以tab健開始。規(guī)則的格式如下：targets：prerequisites commands或targets：prerequisites；commands commandsmakefile的編寫

規(guī)則中的依賴關系：依賴關系是說明文件的關鍵部分，是makefile的核心部分。一個依賴關系說明一個目標依賴于哪些文件以及生成或更新該目標所需要的命令定義格式為：Target-name:[dependent…][;command][(tab)command]makefile示例#anexampleofmakefileprog:main.ox1.ox2.occ–oprogmain.ox1.ox2.omain.o:main.ccc–cmain.cx1.o:x1.ccc–cx1.cx2.o:x2.ccc–cx2.cmake將在3個源文件main.c,x1.c,x2.c中的任何一個發(fā)生變化之后執(zhí)行，重新生成目標程序progmake的宏make的一個主要特性就是它可以定義和使用宏make使用的宏可以分成：

自定義的宏

預定義的宏宏可以簡化makefile描述文件的書寫宏常用來定義makefile中經(jīng)常變化的地方，可以使對makefile的管理更加方便make的宏(2)

自定義的宏：宏既可以在make命令行中定義，也可以在makefile中定義。一旦定義了宏，就可以在makefile的任何地方使用。

宏的引用：$(macro-variable)或${macro-variable}宏的定義：macro-variable=valuemake的宏(3)make的預定義宏：$*$@$<$?$%

表示去掉后綴的當前目標名當前目標的全路徑名為比給定目標文件版本更新的依賴文件名表示所有必須再編譯的目標模塊表示構成庫的模塊文件名

當目標是庫文件時，目標內(nèi)的成員名。例如目標x.a(y.o)的目標名為x.a，成員名為y.omake的宏(4)make的預定義宏：CCCFLAGSCPPFLAGSCOMPILE.sLINK.ccc

$(AS)$(ASFLAGS)$(CC)$(ASFLAGS)$(CPPFLAGS)-c30Makefile文件中的符號“%”%可以理解為統(tǒng)配符?？墒褂盟x或重定義模式規(guī)則。例如:%.o：%.c gcc–c$<定義了一個規(guī)則：所有目標文件*.o依賴C語言源程序*.c；且生成方法為gcc-c$<。31Makefile文件中的符號“=”或“:=”符號“=”或“:=”用于修改已經(jīng)定義的變量或在已定義變量的基礎上定義新變量。例如 已知：var1=a.cb.cc.c

則 var2=$(var1:.c=.o)

定義 var2=a.ob.oc.o

而 var1+=d.c

重定義var1，其值為var1=a.cb.cc.cd.c32“:=”與“=”的區(qū)別“:=”與“=”是有區(qū)別的。當使用“=”時，變量將做遞歸或擴展“:=”只作簡單替換。廈門大學通訊工程系Makefile的Phony目標.PHONY:target不是實際的文件目標常用于clean這類并不產(chǎn)生實際文件的目標34Makefile中的常用目標clean：用于對項目環(huán)境進行準備，清除已經(jīng)生成的目標文件等以便重新編譯；install：用于對整個項目的成品進行安裝；uninstall：則是用于對安裝的項目進行卸載。35Makefile示例1//文件f1.c的內(nèi)容f1(intarg){printf(”F1:youpassed:%d\n”,arg);}//文件f2.c的內(nèi)容：f2(char*arg){printf(”F2:youpassed:%s\n”,arg);}//文件f3.c的內(nèi)容#include<stdio.h>main(){fprintf(stderr,”Begine:\n”);f1(15); f2(”HelloWorld!”);fprintf(stderr,”:End\n”);exit(0);}36Makefile示例2它們之間的關系如下圖37項目編譯過程分析按照gcc的工作過程，對模塊的編譯和鏈接過程可分為：(1)生成目標代碼

gcc-cf1.c gcc-cf2.c gcc-cf3.c(2)生成可執(zhí)行程序gcc-off1.of2.of3.o38Makefile內(nèi)容f:f1.of2.of3.o

gcc-off1.of2.of3.of1.o:f1.c

gcc–cf1.cf2.o:f2.c

gcc–cf2.cf3.o:f3.c

gcc–cf3.c39Makefile的使用有了Makefile文件，可以使用make命令對此項目進行編譯。編譯方法為：

make或makef若要編譯單個項目，比方說f1.o，可以使用以下方法：

makef1.o40增加all、clean和install目標的Makefileall:f #makealltobuildff:f1.of2.of3.o gcc-off1.of2.of3.of1.o:f1.c gcc–cf1.cf2.o:f2.c gcc–cf2.cf3.o:f3.c gcc–cf3.cclean: rm–ff?.o#makeallandinstallfto/usr/binwithpermission755install:all install–m755/usr/local/binmake的宏示例2#exampleoforiginalprog:prog1.oprog2.ogccprog1.oprog2.o-oprogprog1.o:prog1.clib.hgcc-c-I.-oprog1.oprog1.cprog2.o:prog2.cgcc-cprog2.c#examplewithmacroMARCO=prog1.oprog2.oprog:$(MARCO)gccprog1.oprog2.o-o$@prog1.o:prog1.clib.hgcc-c-I.-o$@$<prog2.o:prog2.cgcc-c$*.cmake的后綴規(guī)則make的后綴規(guī)則是make隱含規(guī)則的一種在后綴規(guī)則中，目標和依賴文件名都只使用文件名后綴來代替文件名本身如：make自動認為.o為后綴的目標文件都是依賴以.c和.s為后綴的依賴文件通過后綴規(guī)則可以使用同一條規(guī)則對一系列同類別的文件進行相同的處理，極大地簡化makefile的編寫。

make后綴規(guī)則定義了不同后綴的文件之間的依賴關系。make的后綴規(guī)則示例當make自己定義了一個.c后綴的規(guī)則如下：.c:$(LINK.c)–o$@$<$(LDLIBS)該規(guī)則定義了從C源文件如何得到一個可執(zhí)行文件。此C源文件的名稱將是目的文件的名稱加上.c后綴。若有一個prog.c是只使用標準C庫函數(shù)的程序，其makefile為：prog:make生成目的文件時發(fā)現(xiàn)無此目的文件的依賴文件，就使用隱含規(guī)則“.c:”及prog.c來生成目的文件。自動化編譯

Autoconf介紹內(nèi)容大綱學習目的Autoconf介紹Autoconf框架圖Autoconf流程Autoconf優(yōu)化Autoconf小結FAQ學習目的如何方便在linux系統(tǒng)上寫c/c++等工程的一種技巧，從而提高工程化的能力；方便的閱讀理解開源代碼；容易理解掌握整個工程源碼的架構；寫出優(yōu)秀而漂亮的代碼框架。Autoconf介紹無論是在Linux還是在Unix環(huán)境中，make都是一個非常重要的編譯命令?？梢酝ㄟ^查閱make的幫助文檔來手工編寫Makefile，當然我們更愿意自動生成Makefile。要想了解更多的自動化編譯的知識，不僅僅要熟悉Makefile的語法，還要熟悉m4規(guī)則。實踐還證明：光靠這些規(guī)則理論是不夠的，我們要學會在實踐中創(chuàng)造規(guī)則、完善理論。Autoconf框架圖Autoconf流程-如何寫configure.in在開始antoconf之前，了解一下Autoconf依賴于:Bash,Coreutils,Diffutils,Grep,M4,Make,Perl,Sed.autoscan程序可以用來為軟件包創(chuàng)建configure.in文件。autoscan在以命令行參數(shù)中指定的目錄為根（如果未給定參數(shù)，則以當前目錄為根）的目錄樹中檢查源文件。它為通常的輕便問題搜索源文件，并且為那個包創(chuàng)建一個configure.scan文件，這個文件就是configure.in的前身。autoscan程序是perl語言寫的。將configure.scan文件重命名成configure.in或者configure.ac，并編輯之。configure.in文件中的內(nèi)容都是以AC_INIT開頭，以AC_OUTPUT結束。Autoconf流程-如何寫configure.inconfiugre.in文件的一般布局AC_INIT測試程序測試函數(shù)庫測試頭文件測試類型定義測試結構測試編譯器特性測試庫函數(shù)測試系統(tǒng)調(diào)用AC_OUTPUTAutoconf流程-如何寫configure.in宏含義AC_INIT(FILE)用來檢查源代碼所在的路徑。AM_INIT_AUTOMAKE(PACKAGE,VERSION)這個宏是必須的，它描述了我們將要生成的軟件包的名字及其版本號：PACKAGE是軟件包的名字，VERSION是版本號。當你使用makedist命令時，它會給你生成一個類似helloworld-1.0.tar.gz的軟件發(fā)行包，其中就有對應的軟件包的名字和版本號。AC_PROG_CC檢查系統(tǒng)所用的C編譯器。AC_CHECK_LIB(library,function,[action-if-found],[action-if-not-found],[other-libraries])該宏用來檢查lib庫中是否存在指定的函數(shù)。當測試成功時，執(zhí)行shell命令action_if_found或者action_if_found當為空時，在輸出變量LIBS中添加-llib。action_if_not_found把-lother_libs選項傳給link命令。AC_OUTPUT要輸出的Makefile的名字。AC_LANG_CPLUSPLUS對C++語言的支持。AC_PROG_LIBTOOL對libtool工具的支持。AC_CHECK_HEADERS檢查系統(tǒng)中或環(huán)境路徑中是否存在指定的頭文件，和AC_CHECK_LIB一樣支持條件語句。AC_CHECK_FUNCS檢查libraryfunctions，和AC_CHECK_LIB一樣支持條件語句。Autoconf流程-如何編寫m4文件m4是傳統(tǒng)Unix的宏處理的安裝啟動的應用，其對應的是.m4文件記錄了很多無法理解的宏。詳細的介紹見官方網(wǎng)站：/software/m4/M4文件定義的宏一般需要在configure.in文件中調(diào)用，使用aclocal來進行解析aclocal也是一個perl腳本程序，aclocal根據(jù)configure.in文件的內(nèi)容，自動生成aclocal.m4文件。.m4文件很有趣，很多gcc無法完成的工作，m4可以方便的幫助完成；特別是環(huán)境依賴、系統(tǒng)移植性等方面。Autoconf流程-如何編寫m4文件M4文件的寫法貌似shell腳本，不過更多的是宏的寫法，比如定義一個宏：AC_DEFUN其他常用的宏：AC_ARG_ENABLEAC_ARG_WITHAM_CONDITIONALAC_SUBSTAS_IFAutoconf流程-autoheader負責生成config.h.in文件。該工具通常會從“acconfig.h”文件中復制用戶附加的符號定義，因此此處沒有附加符號定義，所以不需要創(chuàng)建“acconfig.h”文件。Autoconf流程-如何編寫automakeautomake要用的腳本配置文件是Makefile.am，用戶需要自己創(chuàng)建相應的文件。之后，automake工具轉換成Makefile.in。automake有相對應的一些參數(shù)可以配置，比如-a等等可執(zhí)行文件靜態(tài)庫測試文件noinst_PROGRAMS=foofoo_SOURCES=foo_LDADD=foo_LDFLAGS=foo_DEPENDENCIES=noinst_LIBRARIES=libfoo.afoo_a_SOURCES=foo_a_LDADD=foo_a_LIBADD=foo_a_LDFLAGS=check_PROGRAMS=dofoodofoo_SOURCES=dofoo_LDADD=TESTS_ENVIRONMENT=TESTS=$(check_PROGRAMS)Autoconf流程-如何編寫automake目前automake支持三種目錄層次：flat、shallow和deep。Flat指的是所有文件都位于同一個目錄中就是所有源文件、頭文件以及其他庫文件都位于當前目錄中，且沒有子目錄。Termutils就是這一類。shallow指的是主要的源代碼都儲存在頂層目錄，其他各個部分則儲存在子目錄中。就是主要源文件在當前目錄中，而其它一些實現(xiàn)各部分功能的源文件位于各自不同的目錄。Automake本身就是這一類。deep指的是所有源代碼都被儲存在子目錄中；頂層目錄主要包含配置信息。就是所有源文件及自己寫的頭文件位于當前目錄的一個子目錄中，而當前目錄里沒有任何源文件。GNUcpio和GNUtar就是這一類。Yahoo的ydm、dcp等工程也屬于這一類。flat類型是最簡單的，deep類型是最復雜的。但是實際工程中我們經(jīng)常用到的是deep類型的。Autoconf流程-如何編寫automakeMakefile.am中盡量使用相對路徑，系統(tǒng)預定義了兩個基本路徑：$(top_srcdir)工程最頂層目錄，用于引用源程序；$(top_builddir)定義了生成目標文件上最上層目錄，用于引用.o等編譯出來的目標文件。Makefile.am中也類似于m4一樣，定義了很多的宏，比如：includedir頭文件的路徑，等同于-I；也可以使用libfooincludedir指定特定的庫引用的頭文件路徑；include_HEADERS定義需要安裝的頭文件，也可以libfooinclude_HEADERS來指定特定的庫需要安裝的頭文件；一般和libfooincludedir結合使用；Autoconf流程-如何編寫automakedata_DATA需要安裝數(shù)據(jù)文件AUTOMAKE_OPTIONS由于GNU對自己發(fā)布的軟件有嚴格的規(guī)范，比如必須附帶許可證聲明文件COPYING等，否則automake執(zhí)行時會報錯。automake提供了三種軟件等級：foreign、gnu和gnits，讓用戶選擇采用，默認等級為gnu。在本例使用foreign等級，它只檢測必須的文件。bin_PROGRAMS或lib_LIBRARIES定義要產(chǎn)生的執(zhí)行文件名。如果要產(chǎn)生多個執(zhí)行文件，每個文件名用空格隔開。對于可執(zhí)行文件和靜態(tài)庫類型，如果只想編譯，不想安裝到系統(tǒng)中，可以用noinst_PROGRAMS代替bin_PROGRAMS，noinst_LIBRARIES代替lib_LIBRARIES。Autoconf流程-如何編寫automakeMakefile.am還可以支持pkgconfig，對于pc文件也有相應的宏的定義：pcdatadirpc文件的安裝目錄pcdata_DATA安裝的pcdata的文件名稱Autoconf流程-如何編寫automakeMakefile.am還提供了一些全局變量供所有的目標體使用：INCLUDES鏈接時所需要的頭文件LDADD鏈接時所需要的庫文件LDFLAGS鏈接時所需要的庫文件選項標志EXTRA_DIST源程序和一些默認的文件將自動打入.tar.gz包，其它文件若要進入.tar.gz包可以用這種辦法，比如配置文件，數(shù)據(jù)文件等等。SUBDIRS在處理本目錄之前要遞歸處理哪些子目錄Autoconf流程-如何編寫automakeAM_LDFLAGS同LDFLAGS一樣，只是AM_LDFLAGS優(yōu)先加載；AM_CPPFLAGS(AM_CFLAGS)同CPPFLAGS一樣，只是AM_CPPFLAGS優(yōu)先加載；AM_CXXFLAGS同CXXFLAGS一樣，只是AM_CXXFLAGS優(yōu)先加載；CLEANDIRS需要刪除的目錄MOSTLYCLEANFILES需要刪除的文件Autoconf流程—autoconfautoconf是一個用于生成可以自動地配置軟件源碼包，用以適應多種UNIX類系統(tǒng)的shell腳本工具，其中autoconf需要用到m4，便于生成腳本。通過configure.in和aclocal.m4文件，使用autoconf生成configure文件，很復雜的configure文件吧！運行configure文件，生成了我們要的Makefile文件Autoconf優(yōu)化-rpm方案我們知道，創(chuàng)建一個rpm包，需要用到一個spec文件，來注明rpm包的生成信息。在工程項目中一般通常解決方法是在文件的根目錄放一個*.spec.in（用來生成spec文件）或spec文件，這里我結合了.rpmmacros采用了生成spec文件的方式：#definerpmbuildrootRPMBUILDTOPDIR=$(shellunsetRPMBUILDTOPDIR;if[-f${HOME}/.rpmmacros];thenexportRPMBUILDTOPDIR=`grep_topdir${HOME}/.rpmmacros|awk'{print$$2}'`;elseexportRPMBUILDTOPDIR=/usr/src/redhat;fi;echo$${RPMBUILDTOPDIR};)Autoconf優(yōu)化-rpm方案下面的這些有點像Makefile吧，但是這個是在Makefile.am文件中：.PHONY:rpmrpm:dist@PACKAGE@.spec $(RM)${RPMBUILDTOPDIR}/SOURCES/$(distdir).tar.gz $(RM)${RPMBUILDTOPDIR}/SPECS/@PACKAGE@.spec $(LN_S)`pwd`/$(distdir).tar.gz${RPMBUILDTOPDIR}/SOURCES $(LN_S)`pwd`/@PACKAGE@.spec${RPMBUILDTOPDIR}/SPECS rpmbuild-ba${RPMBUILDTOPDIR}/SPECS/@PACKAGE@.spec這樣就可以通過makerpm命令來生成rpm了，值得注意的是如果沒有在.rpmmacros文件內(nèi)指定_topdir，則需要sudo權限來根據(jù)系統(tǒng)變量來生成rpm。Autoconf小結-補充Libtool工具添加需要注意libtoolize步驟針對CFLAGS和CXXFLAGS對默認GNU的編譯選項的更改針對一個lib可以拆分成兩個libdata_DATA需要指定datadir變量的位置AC_HEADER_STDC等宏的合理添加makedist等各種包的打法autoreconf的使用Autoconf小結-FAQ依賴的其他項目是從代碼編譯的，同時他們的makefile是自己寫的一套其他項目從代碼進行編譯的話，可以一次性把編譯好的lib和頭文件放到你工程下的lib和include目錄下，而不是你每次修改自己工程的源文件都需要make一下其他的項目。我們的目的并不是讓別人遵從我們的想法，而是宣揚我們的想法是多么的好，甚至你有更好的想法，我們會一起改進autoconf。make的時候發(fā)生的錯誤有時候奇奇怪怪的，比如鏈接起來了其他代碼片段一般在make出現(xiàn)錯誤了，可以從錯誤代碼原因進行分析，只要你遵守“游戲規(guī)則”，是不會產(chǎn)生鏈接到其它的代碼片段的。這個autoconf如何和java源碼一起編譯我們可以寫Makefile.am，方法如同寫Makefile一樣，把java里面的編譯器，比如ant包含進來，完成我們的make過程即可。Autoconf小結-FAQ執(zhí)行./configure時候出現(xiàn)循環(huán)等問題請重新執(zhí)行aclocal;autoheader;libtoolize--force;automake-a;autoreconf一系列命令，然后./configure，如果make再出現(xiàn)問題，請makeclean后再次make。怎么確定不需要執(zhí)行aclocal等一系列命令一般來說，修改configure.in(ac)或增加（減少）m4文件都需要進行執(zhí)行aclocal等一系列命令,其他比如修改Makefile.am等不需要執(zhí)行。我不會用autoconf，也不會寫makefile學，除非你不想用c/c++。用的多了，經(jīng)常會碰到一些問題，該找誰？Google和gnu的網(wǎng)站源碼控制SCCS軟件開發(fā)過程中，需要不斷對程序進行修改和完善。這種修改和完善時常需要查閱一些早期的版本，甚至要退回到以前的某一版本重新開始。保留所開發(fā)的源程序的各個版本非常有必要，但是這樣會占用大量的存儲空間，而且人工管理相當困難，極易造成混亂建議你選用的版本控制系統(tǒng)包括：rcs，cvs，svn，git，Mercurial，Bazzar等等。UNIX系統(tǒng)為此提供了一個源碼控制系統(tǒng)SCCS，它只記錄對源程序的修改情況，可以對源代碼的多個版本進行有效的管理和控制http://sccs.berlios.de/目前是5.06版本源碼控制SCCS(2)

軟件版本編號：Release.Level.Branch.Sequence發(fā)行號級別號分支號順序號標識一組相似且兼容的版本標識同一發(fā)行版本里各文件存在的主要差異標識在特定級別上的修改標識在一個特定分支上的修改SCCS工作文件SCCS使用不同類型的文件來完成自己的工作。這些文件包含實際的源代碼和SCCS執(zhí)行過程中產(chǎn)生的信息。SCCS在原始的文件名前加上一前綴來命名這些文件。SCCS工作文件(2)s.文件：s.文件是源文件的歷史文件，它包含指定源文件所有版本。它為指定文件的所有版本提供壓縮存儲方式，并自動維護各版本之間的關系。x.文件：由修改SCCS文件的SCCS命令創(chuàng)建，是SCCS文件的一個臨時副本。所有修改SCCS文件的SCCS命令，實際上是對x.文件進行修改z.文件：g.文件：SCCS工作文件(3)為一個封鎖文件。SCCS用它避免多個程序員同時修改一個SCCS文件用指定的s.文件的一個修改清單(delta)替代原始文件的相應部分代碼，從而形成某一版本源代碼的副本，該副本就是g.文件p.文件l.文件SCCS工作文件(4)為SCCS的控制文件，包含當前正在編輯的SCCS文件版本的信息。當一個g.文件從s.文件復原出來時就會產(chǎn)生一個相應的p.文件。它描述了復原出來的g.文件的SID、推薦版本更新后使用的SID，編輯過的g.文件和復原g.文件的用戶名。存放生成給定版本所需使用的delta版本信息SCCS常用命令admingetungetdeltaprs

將源代碼文件置于SCCS控制之下，創(chuàng)建SCCS文件檢查并復原SCCS文件的某一版本的源代碼取消get–e先前對一個文件的作用記錄當前對源代碼文件的修改變化，并創(chuàng)建新的版本按用戶指定的格式打印SCCS文件的各部分

創(chuàng)建SCCS文件$admin–iprogramgram讀取SCCS文件(僅能查看不能編輯)$getgramSCCS命令示例該命令為program文件創(chuàng)建了一個名為gram的SCCS文件，并把記錄prog內(nèi)容的第一個修改清單(delta)復制到gram中該命令從SCCS文件中還原出只讀源文件programSCCS命令示例(2)讀取SCCS文件并獲取寫權限$get-egram記錄源代碼的變化$deltagram該命令使SCCS創(chuàng)建了一個可讀寫的program文件，同時創(chuàng)建一個gram文件該命令執(zhí)行后，將出現(xiàn)提示：comments?給出注釋后，delta會在gram中用此信息對原版本和新版本進行比較，并把所有修改清單復制到SCCS文件中去，形成一個新的deltaGit使用簡介2011/09/20Linux下的分布式版本管理系統(tǒng)git是一個版本控制系統(tǒng)。官方的解釋是：版本控制(Revisioncontrol)是一種軟件工程技巧，籍以在開發(fā)的過程中，確保由不同人所編輯的同一檔案都得到更新。大家怎么合作開發(fā)軟件呢？用信件？效率太低。用郵件，不好實現(xiàn)多人溝通。用googlegroup吧，可開發(fā)階段中的源代碼沒法科學管理。用自建的網(wǎng)站吧，需要人力物力財力來支撐。GitGit是一個版本控制工具它采用了分布式版本庫的方式，不必服務器端軟件支持，使源代碼的發(fā)布和交流極其方便。很多有名的軟件都使用Git來進行版本控制，如Linux內(nèi)核集中式版本管理的流程集中式版本管理的缺點：1、服務器壓力太大，數(shù)據(jù)庫容量暴增。2、如果不能連接到服務器上，基本上不可以工作，看上面第二步，如果服務器不能連接上，就不能提交，還原，對比等等。3、不適合開源開發(fā)（開發(fā)人數(shù)非常非常多，但是Googleappengine就是用svn的）。但是一般集中式管理的有非常明確的權限管理機制（例如分支訪問限制），可以實現(xiàn)分層管理，從而很好的解決開發(fā)人數(shù)眾多的問題。集中式版本管理的優(yōu)點：1、管理方便，邏輯明確，符合一般人思維習慣。2、易于管理，集中式服務器更能保證安全性。3、代碼一致性非常高。4、適合開發(fā)人數(shù)不多的項目開發(fā)。5、大部分軟件配置管理的大學教材都是使用svn和vss。分布式管理的工作流程分布式管理的優(yōu)缺點優(yōu)點：適合分布式開發(fā)，強調(diào)個體。公共服務器壓力和數(shù)據(jù)量都不會太大。速度快、靈活。任意兩個開發(fā)者之間可以很容易的解決沖突。離線工作。

缺點：資料少（起碼中文資料很少）。學習周期相對而言比較長。不符合常規(guī)思維。代碼保密性差，一旦開發(fā)者把整個庫克隆下來就可以完全公開所有代碼和版本信息。Git和其他版本控制系統(tǒng)的主要差別直接快照，而非比較差異Git只關心文件數(shù)據(jù)的整體是否發(fā)生變化，而大多數(shù)其他系統(tǒng)則只關心文件內(nèi)容的具體差異。這類系統(tǒng)（CVS，Subversion，Perforce，Bazaar等等）差別2近乎所有操作都可本地執(zhí)行在Git中的絕大多數(shù)操作都只需要訪問本地文件和資源，不用連網(wǎng)。但如果用CVCS的話，差不多所有操作都需要連接網(wǎng)絡。因為Git在本地磁盤上就保存著所有有關當前項目的歷史更新，所以處理起來速度飛快。差別3時刻保持數(shù)據(jù)完整性在保存到Git之前，所有數(shù)據(jù)都要進行內(nèi)容的校驗和（checksum）計算，并將此結果作為數(shù)據(jù)的唯一標識和索引。換句話說，不可能在你修改了文件或目錄之后，Git一無所知。這項特性作為Git的設計哲學，建在整體架構的最底層。所以如果文件在傳輸時變得不完整，或者磁盤損壞導致文件數(shù)據(jù)缺失，Git都能立即察覺。差別4多數(shù)操作僅添加數(shù)據(jù)常用的Git操作大多僅僅是把數(shù)據(jù)添加到數(shù)據(jù)庫。因為任何一種不可逆的操作，比如刪除數(shù)據(jù)，要回退或重現(xiàn)都會非常困難。概念解釋Gerrit——基于web的代碼審核系統(tǒng)。Gerrit為Git引入的代碼審核是強制性的，就是說除非特別的授權設置，向Git版本庫的推送（Push）必須要經(jīng)過Gerrit服務器，修訂必須經(jīng)過代碼審核的一套工作流之后，才可能經(jīng)批準并納入正式代碼庫中三種狀態(tài)對于任何一個文件，在Git內(nèi)都只有三種狀態(tài)：已提交（committed），已修改（modified）和已暫存（staged）。已提交表示該文件已經(jīng)被安全地保存在本地數(shù)據(jù)庫中了；已修改表示修改了某個文件，但還沒有提交保存；已暫存表示把已修改的文件放在下次提交時要保存的清單中。git概念解釋repository：一個repository就是一組代碼或文本的集合master：主分支，倉庫建立時自動創(chuàng)建HEAD：指向你項目中的當前開發(fā)branchcommit：一個commit包含一次代碼的變更信息,每gitcommit一次代碼,生成一個commitremote：遠程倉庫基本的Git工作流程1.在工作目錄中修改某些文件。

2.對這些修改了的文件作快照，并保存到暫存區(qū)域。3.提交更新，將保存在暫存區(qū)域的文件快照轉儲到git目錄中。安裝Git

概括起來主要有兩種，一種是通過編譯源代碼來安裝；另一種是使用為特定平臺預編譯好的安裝包。在Fedora上用yum安裝：$yuminstallgit-coregit命令linux環(huán)境下git常用操作命令：gitinitgitclonegitlog,gitshow,gitdiffgitadd,gitcommit,gitpush,gitpullgitconfiggitbranch…gitclonegitclone：將項目倉