Vs 2008 解决方案的目录结构设置和管理(转)

http://blog.csdn.net/lcj_cjfykx/article/details/8632459

MS的这个IDE,实在庞杂得恐怖。从大学开始,我就一直用VC的各个版本写程序至今,细细想来,也仅仅是窥豹一斑,羞愧不已。但若仔细翻阅文档,又觉得时间花得不值,于是便一直凑活地用着。

前段时间负责搭建新项目的开发环境,兼一直在看Gamebryo的代码,从中借鉴了不少工程管理的方法。结合以前使用VC的经验,现总结下来与大家分享,希望能起到抛砖引玉的作用。

项目目录结构

VC用解决方案(solution)来表示项目,每个项目由一个或多个工程(project)组成,每个project用来管理一个相对独立的模块。有些大型的项目,例如Gamebryo,甚至会有多个solution:一个solution用来管理LIB或DLL;一个solution用来管理所有的DEMO;一个solution用来管理tools等等。拆分成多个工程,好处之一是结构清晰,二是方便并行开发。每个project由不同的程序员维护,输出LIB或DLL,再链接生成最终的EXE。项目的拆分是很有技术含量的,可以看出设计的功力。拆分得不好,就会产生一些诸如”project间相互依赖”的负面效应。

建立项目的时候,第一件要考虑的事情就是如何配置文件目录结构。如果是只有几个obj的微型项目,将所有东西全部扔到一个目录下也未尝不可(当然,这依然是最糟糕的做法);而对于包含N个project,一大堆的源代码,还有文档,资源等等的大项目,糟糕的文件管理会把事情弄成一团浆糊。优秀的目录配置可以帮助开发者迅速找到需要的东西,很容易就可以添加新的模块和代码,甚至反映出项目的基础架构…最后,好的目录结构,是充满美感的:)

下面就是本人比较喜欢的目录结构设置,实际中根据项目大小和需求有所增减:

src:存放所有的源代码 
build:存放所有的工程文件(solution,project,makefile等) 
doc:项目文档,doxygen文件等 
sdk:工程依赖的所有库文件和头文件 
out:编译器产生的中间文件,目标文件 
bin:编译得到的exe和dll 
上图没有列出来,但通常还会有: 
res:资源目录,可执行文件需要用到的各种图像,声音,模型,场景,UI等资源文件 
script:存放脚本文件 
tool:各种自动化工具

稍微说明一下:一是最重要的源码要单独放一个目录,且不同模块的代码都归置到不同的子目录下。这样的好处是,别人只需要看一眼你的目录结构,就大概知道你工程是怎样的一个架构了。我讨厌所有header放一个目录,所有cpp放另一个目录的做法,想找个文件都很痛苦。

二是工程文件(vc solution,project,makefile等)单独放一个目录。工程文件的重要程度仅次于源码,无工程文件,别人要编译或浏览你的代码都很杯具。插一句,有VC Project的话,Windows下用VC看代码真的是不二之选(当然,Linux下的工具集自不必提),再次就是Editplus+Everything了。话说回来,专业一点的话,build下应该有两个子目录:MSVC和MakeFile,当然还可以有CodeBlock,CodeLite等等。VC工程的话,solution,project和property sheet也应该分开存放

然后就是静态库。每个项目都应该是自给自足的,即整个项目目录我随便copy到什么地方,都照样能编译运行。所以必须要包含所有项目依赖的第三方的库文件和相关的头文件。还有我们的project本身也可能会输出lib,也应该放在同样的目录下,这样方便设置搜索路径。

最后就是编译过程中产生的中间文件,这些我全部扔到out目录里,按"“project_name /[debug | release | shipping] /”分目录存放,一是清理方便,二是看着舒心,最近我还发现这样还能避免链接静态库时的PCH Replacing的问题。而exe和DLL我输出到bin下,Lib则输出到SDK,debug版带后缀_d,release版带后缀_r,类似地shipping版带后缀_s

接下来会具体聊一下project属性的设置…

解决方案与项目:

从VC6之后VC系列就使用解决方案(Solution)来替代原来的工作空间,用于组织和管理多个相关的项目(Project)。

文章首先演示一个虚拟的解决方案和我们期望得到的目录结构,然后使用VC2008的项目设置功能来一步一步达到我们的需求。

虚拟解决方案:

该虚拟解决方案名为GMA,包含一个动态链接库项目ChocolateMilk和一个应用程序项目PureMilk,需要使用一个第三方库log4cxx(Apache log4j的C++移植版本,用于日志输出)。

log4cxx是以动态库的方式编译的,所以我们需要它的3样东西,分别是头文件,导入库(log4cxx.lib, log4cxxd.lib)和动态链接库(log4cxx.dll)。

假设我们期望的目录结构如下图:

1. GMA是解决方案目录

2. PureMilk和ChocolateMilk是项目目录

3. Lib目录用于存放导入库或者静态库(包括第三方库和自己的项目)

4. Include用于存放第三方库的头文件

5. Bin目录存放所有动态链接库和执行档,包括自己的产出和第三方库,区分Release和Debug两个版本。另外,程序运行过程中需要外部的数据文件和启动时需要的配置文件等等都可放于该目录

6. Temp用于存放临时生成文件,其中Compile存放编译器编译时生成的obj文件,Link存放链接器的输出文件。

上面目录结构清晰,一面了然,当我们的程序需要制作安装包或者要打包源码

发布的时候,它能够使得我们生活变得更容易^_^

制作安装包时我们只需将“/GMA/Bin/Release/”目录下的所有文件打包。

发布和转移源码的时候我们可以打包除了Temp目录以外“/GMA/”下面的所有文件和目录(如果不需要执行档,也可不包括Bin)。

我们的需求是明确的,可是VC 2008并不会自动为我们做好上面所有的事情。不过我们并不需要编写复杂的编译脚本(makefile),只需要简单的修改项目的缺省设置即可。

我们需要VC为我们做的事情包括:

1.使用“/GMA/Temp/Compile/”作为项目编译时使用的中间目录

2.使用“/GMA/Temp/Link/”作为项目链接的输出目录

3.当项目是应用程序时,在构建结束后拷贝执行文件到“/GMA/Bin/Release/”或“/GMA/Bin/Debug/”,当项目是动态链接库时,除了拷贝dll到Bin,还拷贝导入库到“/GMA/Lib/”

4.当项目是应用程序时,调试时运行“/GMA/Bin/Debug/”或“/GMA/Bin/Release/”下面的执行文件,并以“/GMA/Bin/Debug/”或“/GMA/Bin/Release/”为工作目录

首先看一下项目设置中可以使用的宏,常用的有:


ConfigurationName

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

IntDir

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

OutDir

链接器使用的输出目录

ProjectDir

项目目录

ProjectName

项目名字

SolutionDir

解决方案目录

TargetDir

目标输出文件所在的目录

TargetExt

目标输出的扩展名

TargetFileName

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

TargetName

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

TargetPath

目标输出文件的全路径名

首先来设置ChocolateMilk:

1.使用“/GMA/Temp/Compile/”作为项目编译时使用的中间目录

2.使用“/GMA/Temp/Link/”作为项目链接的输出目录

注意高亮的部分,首先将配置改成All Configuration(全部配置),这样可以让我们同时修改Debug和Release的部分;

Output Directory(输出目录,链接器)栏位填入:

$(SolutionDir)\Temp\Link\$(ProjectName)\$(ConfigurationName)

Intermediate Directory(中间目录,编译器)栏位填入:

$(SolutionDir)\Temp\Compile\$(ProjectName)\$(ConfigurationName)

3.构建结束后拷贝动态链接库到“/GMA/Bin/Release/”或“/GMA/Bin/Debug/”,拷贝导入库到“/GMA/Lib/”

我们通常都会在Debug版本的输出库后面加上字母“d”以表示这是Debug版本,在Debug配置下,修改Import Library栏位:

VC可以让我们设置构建前后执行的脚本程序,所以为了完成3,

我们需要写构建后执行的脚本:

在Command Line中填入,Debug配置下:

copy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName)\;

copy $(TargetDir)$(TargetName)d.lib $(SolutionDir)\Lib\;

Release配置下:

copy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName)\;

copy $(TargetDir)$(TargetName).lib $(SolutionDir)\Lib\;

之所以要分别设置是因为VC没有表示导入库的宏名字 -_-P

OK,到此为止,你就可以编译ChocolateMilk项目试试是不是一切正常了,不过请确认拷贝的目标目录事先建立好。

接下来我们设置应用程序项目PureMilk:

1.使用“/GMA/Temp/Compile/”作为项目编译时使用的中间目录

2.使用“/GMA/Temp/Link/”作为项目链接的输出目录

首先将配置改成All Configuration(全部配置),这样可以让我们同时修改Debug和Release的部分;

Output Directory(输出目录,链接器)栏位填入:

$(SolutionDir)\Temp\Link\$(ProjectName)\$(ConfigurationName)

Intermediate Directory(中间目录,编译器)栏位填入:

$(SolutionDir)\Temp\Compile\$(ProjectName)\$(ConfigurationName)

3.构建结束后拷贝执行文件到“/GMA/Bin/Release/”或“/GMA/Bin/Debug/”

在Command Line中填入,All配置下:

copy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName);

4.调试时运行“/GMA/Bin/Debug/”或“/GMA/Bin/Release/”下面的执行文件,并以“/GMA/Bin/Debug/”或“/GMA/Bin/Release/”为工作目录

Command栏位填入:$(SolutionDir)\Bin\$(ConfigurationName)\$(TargetFileName)

Working Directory栏位填入:$(SolutionDir)\Bin\$(ConfigurationName)\

这样就大功告成了,现在你就可以编译该执行程序并进行调试。

Visual C++ 使用解决方案来管理项目,项目之间还可能有依赖关系,设置适合自己的解决方案目录结构,便于代码的管理、程序的发布。

下面开始一个虚拟解决方案设计:
        假设此解决方案有应用程序项目A,动态链接库项目B,静态链接库项目C,其中项目A依赖项目B和项目C,则构建解决方案项目结构如下图所示:

而目录结构则如下图所示:

Bin:存放所有动态链接库和可执行程序,分Debug和Release两个版本
A:应用程序项目文件夹
B:动态链接库项目文件夹
C:静态链接库项目文件夹
Doc:存放项目文档
Include:存放引用库的头文件
Lib:存放动态链接库的导入库、静态链接库
Temp:存放临时生成文件,其中Compile存放编译时的中间文件,Link存放链接时的输出文件
除了Doc需要自己建立外,其他文件夹无需手动建立。

项目结构创建步骤:
1.创建一个新应用程序项目,名称A,解决方案名称为Work,如下图所示:

2.在"解决方案资源管理器"右键"解决方案Work","添加"→"新建项目"→"Win32"→"Win32 项目",名称为B,在"应用程序设置"选择"DLL"和"空项目";
3.同样的方式添加一个"Win32项目",名称为C,在"应用程序设置"选择"静态库",去掉"预编译头"选项;
4.项目结构如下图所示:

项目属性设置

配置项目A的属性
1.配置"所有配置","常规",
输出目录:$(SolutionDir)Temp\Link\$(ProjectName)\$(ConfigurationName)
中间目录:$(SolutionDir)Temp\Compile\$(ProjectName)\$(ConfigurationName)

2."生成事件"→"生成后事件",
命令行:echo D | xcopy "$(TargetPath)" "$(SolutionDir)Bin\$(ConfigurationName)" /y
3."C/C++"→"常规",
附加包含目录:$(SolutionDir)Include
4."链接器"→"常规",
附加库目录:$(SolutionDir)Lib
5."调试",
命令:$(SolutionDir)Bin\$(ConfigurationName)\$(TargetFileName)
工作目录:$(SolutionDir)Bin\$(ConfigurationName)

配置项目B的属性
1.配置"所有配置","常规"下,
输出目录:$(SolutionDir)Temp\Link\$(ProjectName)\$(ConfigurationName)
中间目录:$(SolutionDir)Temp\Compile\$(ProjectName)\$(ConfigurationName)
2.配置"Debug","链接器"→"常规"下,
输出文件:$(SolutionDir)Temp\Link\$(ProjectName)\$(ConfigurationName)\$(ProjectName)d.dll
3.配置"所有配置","生成事件"→"生成后事件"下,
命令行:
echo D | xcopy "$(TargetPath)" "$(SolutionDir)Bin\$(ConfigurationName)" /y
echo D | xcopy "$(TargetDir)$(TargetName).lib" "$(SolutionDir)Lib" /y
echo D | xcopy "$(ProjectDir)B.h" "$(SolutionDir)Include" /y 
第三行为xcopy动态库的头文件,实际要根据所需进行改动名称。

配置项目C的属性
1.配置"所有配置","常规"下,
输出目录:$(SolutionDir)Temp\Link\$(ProjectName)\$(ConfigurationName)
中间目录:$(SolutionDir)Temp\Compile\$(ProjectName)\$(ConfigurationName)
2.配置"Debug","管理员"→"常规"下,
输出文件:$(SolutionDir)Temp\Link\$(ProjectName)\$(ConfigurationName)\$(ProjectName)d.lib
3.配置"所有配置","生成事件"→"生成后事件"下,
命令行:
echo D | xcopy "$(TargetPath)" "$(SolutionDir)Lib" /y
echo D | xcopy "$(ProjectDir)C.h" "$(SolutionDir)Include" /y 
第二行为xcopy静态库的头文件,实际要根据所需进行改动名称。

最后设置项目生成顺序
菜单栏→"项目"→"项目依赖项",项目A依赖于B和C,如下图所示:

编译生成,可看到如下结果:

用tree命令看下文件夹结构:

其他网上关于目录结构配置资料:
1.VC 2005 解决方案的目录结构设置和管理  http://blog.csdn.net/rogeryi/article/details/1481923
2.VC项目管理:目录结构  http://www.fancystar.org
3.VS2008中VC项目文件目录的管理  http://qimo601.iteye.com/blog/1059299
4.研发规范-VC http://wenku.baidu.com/view/26f6c789680203d8ce2f2414.html

时间: 2024-10-06 20:56:32

Vs 2008 解决方案的目录结构设置和管理(转)的相关文章

Visual Studio解决方案的目录结构设置和管理

摘至:http://blog.csdn.net/lp310018931/article/details/47991759 首先,解决方案和项目文件夹包含关系(c++项目): VS解决方案和各个项目文件夹以及解决方案和各个项目对应的配置文件包含关系,假设新建一个项目ssyy,解决方案起名fangan,注意解决方案包括项 目,此时生成的最外层目录为fangan代表整个解决方案的内容都在这个文件夹内.在这个fangan文件夹内包含有fangan.sln的解决方案配置 文件和一个ssyy文件夹,ssyy

VS解决方案的目录结构设置和管理

一个中等规模的解决方案通常都会包含多个项目,其中一些项目产出静态库,一些产出动态库,一些用于单元测试,还有的产出最终的应用程序执行档.除此以外,根据项目的需求,还会使用一些第三方的库. 所以为解决方案设置一个合理的目录结构,不但可以使得代码管理更井井有条,项目成员之间也更容易相互配合,更重要的是能够使得最终应用程序的安装包制作,源代码打包发布和转移变得十分容易. 解决方案与项目: 从VC6之后VC系列就使用解决方案(Solution)来替代原来的工作空间,用于组织和管理多个相关的项目(Proje

VS下的解决方案目录结构设置和管理

转载:http://blog.csdn.net/pl20140910/article/details/52074165 为了方便管理自己写的代码,也为了日后工作能方便的查找之前做过相同的代码,仿照某源码结构,自己建了一个解决方案,以方便管理自己的代码,这样代码迁移也比较方便,不需要每次重新配置第三方库或其它需要依赖的库.下图为整个解决方案目录结构设置: 图1 VS解决方案目录结构设置 如上图,为了方便管理,以后所有的项目都写在AllProject解决方案里,途中红色的部分表示的都是文件夹,绿色的

[Ecmall]ECMALL目录结构设置与数据库表

最近在做ecmall的开发,ecmall在开源方面还有待进步啊,官方没有提供开发文档,也没有关于系统架构组织的贡献,使用者都要自己从0开始,官方论坛连二次开发板块都没有,都在哪瞎扯淡,广告一堆.可悲~~~ 自己做了一张图片,根据ecmall的程序结构图,可以清楚的知道ecmall的五脏六腑. ECMALL数据库主要表 ecm_acategory:存放的是商城的文章分类. ecm_address:存放的是店长的地址 ecm_article:存放的是商城的相关文章 ecm_brand:存放的是商城的

ECMALL目录结构设置与数据库表

最近在做ecmall的开发,ecmall在开源方面还有待进步啊,官方没有提供开发文档,也没有关于系统架构组织的贡献,使用者都要自己从0开始,官方论坛连二次开发板块都没有,都在哪瞎扯淡,广告一堆.可悲~~~ 自己做了一张图片,根据ecmall的程序结构图,可以清楚的知道ecmall的五脏六腑. ECMALL数据库主要表 ecm_acategory:存放的是商城的文章分类. ecm_address:存放的是店长的地址 ecm_article:存放的是商城的相关文章 ecm_brand:存放的是商城的

关于Tomcat的点点滴滴(体系架构、处理http请求的过程、安装和配置、目录结构、设置压缩和对中文文件名的支持、以及Catalina这个名字的由来……等)

总结Tomcat的体系架构.处理http请求的过程.安装和配置.目录结构.设置压缩和对中文文件名的支持.以及Catalina这个名字的由来--等. Tomcat和JVM: 一个Tomcat只会启动一个JVM,所有webapps公用一个JVM进程,所以System.exit()会导致影响同个Tomcat中的其他应用.Tomcat通过调用配置的JDK或JRE来启动JVM. 体系结构: Server:A Server element represents the entire Catalina ser

02_Weblogic课程之安装篇:RedHat下JDK安装,RedHat下Weblogic安装,目录结构,环境变量设置

 1  Weblogic的安装方式有三种: 一.GUI方式安装    (java –jar wls1035_generic.jar [-mode=gui])这是默认的 二.Console方式安装   (java –jar wls1035_generic.jar –mode=console) 三.Silent方式安装(静默方式) :这种方式不需要认为干预,默认安装的,适合作集群的时候使用,需要一个配置文件    (java –jar wls1035_generic.jar –mode=sile

(转)关于Tomcat的点点滴滴(体系架构、处理http请求的过程、安装和配置、目录结构、设置压缩和对中文文件名的支持、以及Catalina这个名字的由来……等)

转自:http://itfish.net/article/41668.html 总结Tomcat的体系架构.处理http请求的过程.安装和配置.目录结构.设置压缩和对中文文件名的支持.以及Catalina这个名字的由来--等. Tomcat和JVM: 一个Tomcat只会启动一个JVM,所有webapps公用一个JVM进程,所以System.exit()会导致影响同个Tomcat中的其他应用.Tomcat通过调用配置的JDK或JRE来启动JVM. 体系结构: Server:A Server el

Day4 - 迭代器&生成器、装饰器、Json & pickle 数据序列化、软件目录结构规范

---恢复内容开始--- 本节内容 迭代器&生成器 装饰器 Json & pickle 数据序列化 软件目录结构规范 作业:ATM项目开发 1.列表生成式,迭代器&生成器 列表生成式 需求:列表a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9],要求把列表里的每个值加1 1 a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2 b = [] 3 for i in a: 4 b.append(i+1) 5 a = b 6 print(a) 普通青