項目框架設計模式（轉）

轉自 http://my.huhoo.net/archives/2009/08/post_39.html

項目框架設計模式

目的

1. 解決多人開發過程當中協做的問題；
2. 解決配置文件規範；
3. 解決項目源碼包和二進制打包的問題；
4. 解決文檔規範；

目錄 1 目的 2 框架 3 常約定 3.1 配置文件 3.2 庫公約 4 樣例

目的

 

1. 解決多人開發過程當中協做的問題；
   
2. 解決配置文件規範；
   
3. 解決項目源碼包和二進制打包的問題；
   
4. 解決文檔規範；
   

框架

 

• 結合git和autoconf，能夠達到多人的協做開發模式；
  

• 上圖中利用autoconf的開發模式，能有效的達到各項的「產出」,具體介紹可瀏覽autoconf介紹，若是多我的進行開發，能夠選擇svn或者git，這裏有一個大概介紹git的開發模式圖：
  

常約定

• 在瞭解大概的模式以後，咱們還要了解常常在一些開發和項目中的約定（常約定）。
  

配置文件

• 在實際的工程項目中，咱們通常使用如下幾種類型的配置文件：
  
  1. unixconfig經常使用於在unix環境中讀取配置信息的一種格式，這種格式被衆多開源程序所用，是最普遍的一種配置文件類型；
     
  2. libconfig是基於自定義的一套數據結構格式，數據結構能夠很複雜，也是開源程序常用一種方式，最近cnangel作了針對perl讀寫的模塊，這樣能夠兼容perl語言、C/C++語言；
     
  3. xml格式是一種常見的數據結構，但也經常使用於做配置文件，通常在java工程中常用，c/c++並不常見；
     
  4. yaml是一種包含xml等子集的數據格式，在yaml官方網站有yaml的標準規範，且yaml支持多種語言，可是c/c++庫提供的庫並非很適合作配置文件，因此此配置類型每每用於腳本；
     
  
  
• 詳細格式見下圖：
  

庫公約

• 針對c/c++開發的項目，咱們針對各類平臺通常最終須要提供動態連接庫和靜態連接庫；
  
• 對於靜態庫文件，咱們常見的Windows平臺中通常是.lib爲擴展名，類Unix平臺中以.a爲擴展名，裏面相同的都是由一些C或者其餘語言生成的object（.o爲擴展名）文件打包而成；
  
• 對於動態連接庫文件，通常在Windows平臺中是以.dll做爲擴展名，類Unix平臺中以.so做爲擴展名，裏面都是一些符號鏈接和函數的聲明、構造信息等等，通常可使用工具nm等查看到相關信息,ldd來查看符號鏈接、依賴等信息；
  
• 靜態庫文件通常比動態鏈接庫大得多，靜態庫能夠解出多個.o結尾的object文件，經過這個方法，咱們能夠合併不少小的靜態庫，併合並相應的頭文件。靜態庫的信息相對比較全，主要用來做開發等；
  
• 動態庫相對來講只有一些符號鏈接等信息，每每用來支配程序（可執行文件）的運行，並且比靜態庫會獲取到更小的內存空間，從而節省了程序的運行空間；
  
• 類Unix動態連接庫標準命名規則(soname)：
  

  lib + 連接庫名字 + .so + .版本號

 

每當連接庫接口改變時都遞增版本號。soname 文件其實只是一個符號連接而已，指向他的real name 文件，更爲詳細的命令方式以下(real name)：

  lib + 連接庫名字 + .so + .版本號.次版本號.發行號

 

• 實際上，咱們鏈接庫時，使用的是以下動態連接庫(linker name)：
  

  lib + 連接庫名字 + .so

 

編譯器以這個名字來請求指定的連接庫。

• 當程序在內部列出所須要的連接庫時，僅僅使用連接庫名字。當你建立一個連接庫時，使用 real
  name。安裝一個新的連接庫時，把它複製到一個DLL文件夾裏，而後運行程序 ldconfig。ldconfig 檢查存在的 real name
  文件，而且建立指向它的符號連接 soname 文件。ldconfig 並從新創建 cache 文件 /etc/ld.so.cache。
  
• ldconfig 不會建立 linker name 文件，可是通常性 linker name
  文件在安裝連接庫的時候建立。linker name 文件也只是一個符號連接，指向最新的 soname 文件或 real name
  文件。建議指向 soname 文件，由於當你更新庫之後，在編譯器連接的時候，通常老是想使用新的庫。
  
• 通常而言，連接庫必須放置在文件系統的指定位置。
  
  1. 多數開源軟件遵照 GNU 標準：當分發源代碼的時候，庫默認安裝在 /usr/local/lib，命令安裝在 /usr/local/bin。該標準還定義瞭如何重寫這些默認標準以及如何調用安裝程序。
     
  2. Filesystem Hierarchy Standard(FHS) 規定：多數庫應安裝在 /usr/lib，啓動時須要的庫安裝在 /lib，非系統庫應安裝在 /usr/local/lib
     
  
  
• GNU 標準是針對開發人員的，FHS 是針對發行者的。
  
• 在基於 GNU glibc 的系統上，包括全部 linux 系統，ELF
  可執行二進制文件的運行自動致使程序加載器被加載而且運行。在 linux 下，加載器是
  /lib/ld-linux.so.X（X是版本號）。而後加載器搜索、加載程序所要使用的動態連接庫，被搜索的文件夾列表保存在文件
  /etc/ld.so.conf 裏。
  
• 使用環境變量LD_LIBRARY_PATH, 該變量所指定的文件夾將會首先被搜索，而後纔會搜索默認的連接庫文件夾。該變量對開發和測試比較有用，但不該該爲了給普通用戶使用而設置。
  
• 在Linux下你能夠直接調用程序加載器，好比，你能夠傳遞PATH參數給加載器代替該變量來運行程序：
  

/lib/ld-linux.so.2 --library-path PATH EXECUTABLE

不帶參數執行加載器，能夠獲得更多幫助。可是，不要這樣執行程序，僅供調試時使用。

• 另外環境變量LD_DEBUG供調試使用的。該變量是dl*函數的開關，用來顯示正在作的事情的詳細信息。能夠取值爲：
  

參數	解釋
files	顯示so文件的加載順序
bindings	顯示關於符號幫定的信息
libs	顯示庫搜索路徑的信息
versions	顯示版本依賴的信息
help	使用該值運行程序將會顯示可用的選項

• 在GNU的編譯器中(gcc)，不少的編譯選項可以很好的輔助咱們來建立動態鏈接庫；
  
  • 用 -fpic 或 -fPIC 選項建立要放入動態連接庫中的目標文件。使用該選項生成的代碼是位置無關的代碼（動態連接庫的必要條件）。使用 gcc 的 -Wl 選項傳遞 soname 參數給連接器。-Wl 選項裏不能有未轉義的 whitespace。
    
  • -g 選項使代碼包含調試信息，-Wall 選項用來產生警告，二者並非建立動態連接庫必須的，可是建議加上。
    
  • 不要 strip 所生成的動態連接庫，或使用編譯器參數 -fomit-frame-pointer，這樣作將會沒法使用調試器。
    
  • -fPIC 選項老是可使用，但生成的代碼比使用 -fpic 的要大。-fpic 選項生成的代碼比較小、快，可是有平臺相關的限制，當建立 DLL 時，連接器將會告訴你是否符合限制。
    
  • 連接器還有一個有用的選項 -rpath，能夠用來指定程序在運行時搜索DLL時的路徑，使用 gcc 時能夠這樣傳遞參數給連接器：
    

  -Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)

 

若使用了這個選項，就能夠考慮不用LD_LIBRARY_PATH這個環境變量了。

樣例

• 這裏用了一個工程uc做爲用例來講明該框架的強大以及靈活多變的可擴展性(目前版本是0.0.2-2版本)：
  

  http://github.com/cnangel/UC/tree/master