第三方开发包在使用时有如下特点：每个产品有各自不同的目录结构，组织的方式不统一，直接使用将增加引用和依赖关系的复杂性；产品目录全部展开后有时文件数量非常庞大，如果直接纳入配置管理的话，加入源码控制的开销很大，而当其版本升级时替换原有文件更是非常繁琐且容易出错，但是不控制的话又会造成第三方开发包版本冲突和安装路径不一致的问题；项目中对第三方开发包的引用，通常不直接使用其源码，而是链接其编译好的静态库。
针对上述特点，本项目对第三方开发包的源码结构组织如下图所示：
目录
说明
备注
zipped
第三方产品的发布包，通常为zip压缩文件
纳入配置管理
build
构建脚本以及IDE项目文件
纳入配置管理
test
验证第三方产品是否成功编译、安装的测试代码
如果自行编写或修改了测试代码则纳入配置管理
build_space
用于第三方产品进行解包、编译和安装的临时场所
临时目录，不纳入配置管理
include
第三方产品公开头文件（即Interface）的安装目标目录，项目其它构件通过设置环境变量来增添一条指向它的头文件包含查找路径
通常由构建脚本在安装步骤中自动拷贝
lib
第三方产品最终提供给项目其它构件引用的静态库和动态库
通常由构建脚本在编译、安装步骤生成
doc
第三方产品的用户参考文档
通常由构建脚本在安装步骤中自动拷贝
bin
可执行文件
通常由构建脚本在编译、安装步骤生成
本方案中，纳入配置管理的通常只有第三方产品的发布包（zip压缩文件），和能够自动将第三方产品进行构建和安装的构建脚本。项目将在各基线中保持其不同版本的发布包，版本控制变得非常简单，而构建脚本的执行能确保正确的发布版本安装到目标开发空间，供项目其它构件引用。第三方产品虽然本身展开的目录各自不同，但是其安装后的目标目录结构却完全一样，其它构件只需要到include下找头文件，到lib下找需要链接的库文件，引用依赖关系变得简单明了。
构建脚本的执行步骤：
首先执行初始化（-Init），准备好编译工具配置；执行清除工作（Clean），得到干净的工作空间；完成构建准备（-Prep），创建一些临时目录（build_space）和目标目录（include）；进行解包工作（Unpack），将第三方产品解压到build_space；进行自动编译（AutoBuild），在build_space目录之下生成目标库和可执行文件；开启安装过程（Install），将公开头文件（即Interface）自动拷贝到include下，将用户参考文档拷贝到doc下，将静态库和动态库拷贝到lib下，将可执行文件拷贝到bin下，最后再设置一个环境变量指向本开发包的当前根目录；执行测试准备（-TestPrep），从第三方发布包中组织相关的测试代码，拷贝到test下；进行测试构建（TestBuild），生成测试执行文件；执行测试（Test），验证第三方产品安装成功，使用它的构件可以正常编译，并且可以通过测试。
引用第三方发布包的示例：
执行log4cplus开发包的构建脚本后（保证安装过程Install已正确完成），将在D:\Development_Home\Building.Workspace\ env.properties文件中增添一条属性记录 getenv.LOG4CPLUS_ROOT=K\:\\PCHL_V1_Dev\\Libraries\\log4cplus；并添加一个环境变量（限于Windows NT平台）指向本开发包的当前根目录LOG4CPLUS_ROOT=K:\PCHL_V1_Dev\Libraries\log4cplus。
引用构件如果使用Ant脚本，则要在脚本中引用env.properties文件，然后于编译任务中，使用getenv.LOG4CPLUS_ROOT属性，分别在includepath段添加${getenv.LOG4CPLUS_ROOT}\include路径，和在libset段使用${getenv.LOG4CPLUS_ROOT}\lib目录来指引log4cplus.lib等静态链接库。
引用构件如果使用msvc6 IDE，则在项目文件中分别添加%LOG4CPLUS_ROOT%\include头文件查找路径和%LOG4CPLUS_ROOT%\lib库文件查找路径。
而在引用构件的源码中使用类似以下的格式来包含log4cplus的公开头文件：
#include <log4cplus/socketappender.h>
#include <log4cplus/helpers/socket.h>
本文地址：http://com.8s8s.com/it/it37289.htm