平凡的世界

神鹰忽展翅,头顶青天飞
随笔 - 10, 文章 - 0, 评论 - 34, 引用 - 0
数据加载中……

软件工程配置规范(VC2005) 第二版

版本号

日期

修改者

说明

备注

0.1

2010.07.13

phoenix

   

0.2

2011.01.12

phoenix

   
         
         
         


目 录

1. 引言... 1

1.1. 编写目的.. 1

1.2. 参考资料.. 1

2. 目录结构... 1

3. 工程配置... 2

4. 属性配置... 2

4.1. “常规”配置.. 2

4.2. “调试”配置.. 2

4.3. “C/C++”配置.. 3

4.4. “链接器”配置.. 3

4.5. “生成事件”配置.. 3

5. 附录:VC2005中可以使用的宏... 3

1.引言

1.1.编写目的

当开发人员开始进行编码工作以及编码工作的过程中,都需要根据工程的需要配置各种工作路径,如引入第三方库、输出生成的头文件和库文件等。以前部分开发人员对工程路径的定义比较随意,相当一部分使用的是绝对路径。如果只是单个开发人员完成一个单一的功能,这种做法看起来没有什么明显的缺点。但是,如果是数个开发人员来合作共同完成一个功能和结构都很复杂的工程时,这种做法的弊端就凸显出来。一个非常明显的问题就是:开发人员A将他的工程交给开发人员B编译时,如工程定义使用了绝对路径,除非开发人员B的计算机与A的计算机具有完全相同的文件组织结构,否则一次性编译通过是不可能。另外,当开发人员在一长串的“Can’t find …”或者“XXX undefined”的错误与警告中焦头烂额时,也许只是因为一个不起眼的地方使用了绝对路径,或者是大小写的差异。

因此,规范开发人员的工程配置是很有必要的。通过规范的工程配置,所有开发人员之间的工程是无缝衔接的,即任何一个开发人员的工程拿到其他人的工程时,无须修改任何一个配置便可以一次性的编译成功。这样的规范操作无异可以大大减少团队成员通过代码交流时的不必要成本。另外,规范的工程配置也便于SubVersion版本控制系统的引入,通过引入SubVersion版本控制系统,可以协调整个研发团队的工程进度,控制产品的里程碑发布。这一切,都从规范的工程配置开始。

1.2.参考资料

1. 《OpenSource SubVersion规范》

2. 《Visual Studio 2005编程指南》

2.目录结构

MyDevelopeFolder

├─Bin

│ ├─Debug

│ ├─Program

│ ├─Release

│ ├─UnicodeDebug

│ ├─UnicodeProgram

│ └─UnicodeRelease

├─MySDK

│ ├─Include

│ │ ├─BCG

│ │ └─Boost

│ └─Lib

│ ├─Debug

│ │ ├─BCG

│ │ └─Boost

│ ├─Program

│ │ ├─BCG

│ │ └─Boost

│ ├─Release

│ │ ├─BCG

│ │ └─Boost

│ ├─UnicodeDebug

│ │ ├─BCG

│ │ └─Boost

│ ├─UnicodeProgram

│ │ ├─BCG

│ │ └─Boost

│ └─UnicodeRelease

│ ├─BCG

│ └─Boost

├─Project

│ ├─LibMyExample

│ │ └─Document

│ └─MyExampleApp

│ └─Document

├─Solution

└─Temp

├─Compile

└─Link

1. MyDevelopeFolder是开发工程的根目录

2. Bin目录存放所有动态链接库和可执行程序,包括自己的产出和第三方库,按编译配置名称包括对应的子目录,如Debug、Release。另外,程序运行过程中需要外部的数据文件和启动时需要的配置文件等等都可放于该目录

3. MySDK存放产品项目依赖、产出的.h文件和.lib文件。其中Lib目录下根据配置名称和第三方库名称对lib文件进行管理。如某项目使用BCG作为界面库,则BCG的头文件放置于“Include\BCG”下,不同版本的库文件置于“Lib\配置名\BCG”下;项目输出的lib文件直接位于“Lib\配置名”下。这样产品依赖的不同开发库所使用头文件与库文件和输出的头文件与库文件相互之间是独立、彼此不干涉的。

4. Project是工程目录,用于存放代码,按模块名组织次级目录。功能库工程一般的以“Lib”开头,以便与其它动态库区别。每个工程模块目录应包含“Document”子目录,该目录下按需要增加“DBM”、“DOC”、“UML”三个子目录。“DBM”用于存放与该模块相关的数据库设计文档,通常是PowerDesigner文档;“DOC”用于存放与该模块相关的一般性说明文档;“UML”用于存放与该模块相关的UML设计文档,通常是Rational Rose文档。

5. Solution是解决方案目录,用于存放产品的完整解决方案。通常使用解决方案可以生成该产品的所有版本。

6. Temp是用于编译生成的中间目录,主要存放编译过程中生成的各种中间文件。

3.工程配置

根据调试信息与字符集的不同,一般的工程配置有六类,如下表所示

名称

字符集

是否包含调试信息

是否包含代码优化

Debug

ANSI

YES

NO

Release

ANSI

YES

YES

Program

ANSI

NO

YES

UnicodeDebug

UNICODE

YES

NO

UnicodeRelease

UNICODE

YES

YES

UnicodeProgram

UNICODE

NO

YES

4.属性配置

4.1.“常规”配置

输出目录: ..\..\Temp\Link\$(ProjectName)\$(ConfigurationName)

中间目录:..\..\Temp\Compile\$(ProjectName)\$(ConfigurationName)

4.2.“调试”配置

如果需要启动本模块进行调试,则“命令”为:..\..\Bin\$(ConfigurationName)\$(TargetFileName)

4.3.“C/C++”配置

1) “附加包含目录”:..\..\MineSDK\Include ,如有其它目录请用“;”间隔,注意使用相对路径,严禁使用绝对路径

2) 动态库使用导出宏导出/导入时,应在“预处理器”中定义导出宏,不得在代码文件中定义。导出宏的一般格式为“LIB_XXXXX”。

3) 一般情况下不推荐使用预编译头。

4.4.“链接器”配置

1) “输出文件”:

a) 若为Debug版时:$(OutDir)\$(ProjectName)D.dll;

b) 若为Release版时:$(OutDir)\$(ProjectName).dll。

2) “附加库目录”:..\..\Bin\$(ConfigurationName);..\..\MySDK\Lib,如有其它目录请用“;”间隔,注意使用相对路径,严格禁止使用本地绝对路径。

3) “模块定义文件”:一般不使用模块定义.def文件,本项可选择“从默认配置…”。

4.5.“生成事件”配置

一般需要配置的是“生成后事件”。任何一个工程模块的生成后事件都应包括以下内容:

1) copy $(TargetPath) ..\..\Bin\$(ConfigurationName)

2) 若有导出的Lib库文件,需要增加:copy $(TargetDir)$(TargetName).lib ..\..\MySDK\Lib

3) 若有导出的头文件,需要增加: copy myhead.h ..\..\MySDK\Include

具体文件名与路径视情况而定,但是严禁使用绝对路径。

5.附录:VC2005中可以使用的宏

ConfigurationName

配置名字,通常是Debug或者Release

IntDir

编译器使用的中间目录,产出obj文件

OutDir

链接器使用的输出目录

ProjectDir

项目目录

ProjectName

项目名字

SolutionDir

解决方案目录

TargetDir

目标输出文件所在的目录

TargetExt

目标输出的扩展名

TargetFileName

目标输出文件名,包括扩展名

TargetName

目标输出名,不包括扩展名

TargetPath

目标输出文件的全路径名

posted on 2011-04-03 18:58 西门有悔 阅读(2110) 评论(6)  编辑 收藏 引用

评论

# re: 软件工程配置规范(VC2005) 第二版  回复  更多评论   

希望可以放出pdf版,这样方便使用……
2011-04-03 20:19 | 御用软件

# re: 软件工程配置规范(VC2005) 第二版  回复  更多评论   

个人非常讨厌什么 bin,source,solution,。。。
你要么就纯粹自己搞,bin、source 都可以,就别 solution、project 了,最后自己写脚本
要么就用 solution、project,目录就大体上按默认的,一个project一个目录,
既用 solution、project,又独立搞一套目录体系,然后修改一大堆纯粹关于目录的配置参数,何必呢
2011-04-03 21:52 | 溪流

# re: 软件工程配置规范(VC2005) 第二版  回复  更多评论   

@溪流
1.Bin里是所有生成的文件,包含了程序可以运行的最小资源,产品发布人员只需要将Bin里的文件打包就可以生成安装文件。而默认的配置会在bin目录里生成程序调试数据库等一些非运行时需要的文件。Bin是面向产品测试与发布人员的,开发人员只是将dll和exe输出到bin中进行调试。这样使产品开发与产品测试、发布分开。
2.Project与Solution分开是因为每个成员都是独立地开发一个或几个Project的,他把Bin与SDK从SVN上checkout出来,就可以进行自己的代码编写,而不必关心与其他开发人员所同时进行的project的依赖关系。Solution里包含的是整个产品的所有project以及project之间的依赖关系。打开solution就可以生成一个完整的产品到bin里,而且bin里没有任何多余的文件。

效果:采用了这套工程配置方法,整个团队代码与工程层面的交流明显顺畅多了,再也没有出现拿到别人的工程半天build不过的问题。而且开发与测试、发布之间的卸接也很顺利。开发人员每天都build后commit到svn。每周一开发部产品管理员用solution生成一个完成的bin并整理出track后发布到Svn上,测试人员用本周一的bin进行测试,到了Tag的时间点测试部产品管理员将bin打包成安装程序发布到svn上并通知实施部门有更新版本。形成一个完整的流程。再用bugzilla与dotproject对产品的bug和人员进行管理。

总结:这套工程配置应该算是不依赖于第三方工具,进行基于Svn的代码管理以及多个开发人员之间的合作开发。如果是一个人,或者project不多的时候就没必要如此复杂。而且修改工程配置是一次的,不需要每次都修改。可以说一劳永逸。

谢谢你的评论。
2011-04-04 00:43 | 西门有悔

# re: 软件工程配置规范(VC2005) 第二版  回复  更多评论   

1、打包人员不该偷懒,他们应该知道完整的精确的文件清单,而不仅仅是“某个目录下的所有文件”
2、还是没有看出来把solution单独藏在一个目录的用意。
2011-04-04 11:58 | 溪流

# re: 软件工程配置规范(VC2005) 第二版[未登录]  回复  更多评论   

可参考 chrome 或者 svn乌龟 等开源项目的目录组织,
我们都是每天自动构建, 自动生成安装包等
2011-04-06 08:56 | chentan

# re: 软件工程配置规范(VC2005) 第二版  回复  更多评论   

@溪流
打包人员不该偷懒,他们应该知道完整的精确的文件清单,而不仅仅是“某个目录下的所有文件”

他们通常不知道 你也很难让他们知道
2011-04-07 12:44 | houwukong

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理