项目框架设计模式

目的

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*函数的开关，用来显示正在做的事情的详细信息。可以取值为：
  

• 在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