版 本 控 制
| 版本號 | 日期 | 修改者 | 說明 | 備注 |
| 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
當開發人員開始進行編碼工作以及編碼工作的過程中，都需要根據工程的需要配置各種工作路徑，如引入第三方庫、輸出生成的頭文件和庫文件等。以前部分開發人員對工程路徑的定義比較隨意，相當一部分使用的是絕對路徑。如果只是單個開發人員完成一個單一的功能，這種做法看起來沒有什么明顯的缺點。但是，如果是數個開發人員來合作共同完成一個功能和結構都很復雜的工程時，這種做法的弊端就凸顯出來。一個非常明顯的問題就是：開發人員A將他的工程交給開發人員B編譯時，如工程定義使用了絕對路徑，除非開發人員B的計算機與A的計算機具有完全相同的文件組織結構，否則一次性編譯通過是不可能。另外，當開發人員在一長串的“Can’t find …”或者“XXX undefined”的錯誤與警告中焦頭爛額時，也許只是因為一個不起眼的地方使用了絕對路徑，或者是大小寫的差異。
因此，規范開發人員的工程配置是很有必要的。通過規范的工程配置，所有開發人員之間的工程是無縫銜接的，即任何一個開發人員的工程拿到其他人的工程時，無須修改任何一個配置便可以一次性的編譯成功。這樣的規范操作無異可以大大減少團隊成員通過代碼交流時的不必要成本。另外，規范的工程配置也便于SubVersion版本控制系統的引入，通過引入SubVersion版本控制系統，可以協調整個研發團隊的工程進度，控制產品的里程碑發布。這一切，都從規范的工程配置開始。
1. 《OpenSource SubVersion規范》
2. 《Visual Studio 2005編程指南》
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是用于編譯生成的中間目錄，主要存放編譯過程中生成的各種中間文件。
根據調試信息與字符集的不同，一般的工程配置有六類，如下表所示
| 名稱 | 字符集 | 是否包含調試信息 | 是否包含代碼優化 |
| Debug | ANSI | YES | NO |
| Release | ANSI | YES | YES |
| Program | ANSI | NO | YES |
| UnicodeDebug | UNICODE | YES | NO |
| UnicodeRelease | UNICODE | YES | YES |
| UnicodeProgram | UNICODE | NO | YES |
輸出目錄： ..\..\Temp\Link\$(ProjectName)\$(ConfigurationName)
中間目錄：..\..\Temp\Compile\$(ProjectName)\$(ConfigurationName)
如果需要啟動本模塊進行調試，則“命令”為：..\..\Bin\$(ConfigurationName)\$(TargetFileName)
1) “附加包含目錄”：..\..\MineSDK\Include ，如有其它目錄請用“;”間隔，注意使用相對路徑，嚴禁使用絕對路徑。
2) 動態庫使用導出宏導出/導入時，應在“預處理器”中定義導出宏，不得在代碼文件中定義。導出宏的一般格式為“LIB_XXXXX”。
3) 一般情況下不推薦使用預編譯頭。
1) “輸出文件”：
a) 若為Debug版時：$(OutDir)\$(ProjectName)D.dll；
b) 若為Release版時：$(OutDir)\$(ProjectName).dll。
2) “附加庫目錄”：..\..\Bin\$(ConfigurationName);..\..\MySDK\Lib，如有其它目錄請用“;”間隔，注意使用相對路徑，嚴格禁止使用本地絕對路徑。
3) “模塊定義文件”：一般不使用模塊定義.def文件，本項可選擇“從默認配置…”。
一般需要配置的是“生成后事件”。任何一個工程模塊的生成后事件都應包括以下內容：
1) copy $(TargetPath) ..\..\Bin\$(ConfigurationName)
2) 若有導出的Lib庫文件，需要增加：copy $(TargetDir)$(TargetName).lib ..\..\MySDK\Lib
3) 若有導出的頭文件，需要增加： copy myhead.h ..\..\MySDK\Include
具體文件名與路徑視情況而定，但是嚴禁使用絕對路徑。
| ConfigurationName | 配置名字，通常是Debug或者Release |
| IntDir | 編譯器使用的中間目錄，產出obj文件 |
| OutDir | 鏈接器使用的輸出目錄 |
| ProjectDir | 項目目錄 |
| ProjectName | 項目名字 |
| SolutionDir | 解決方案目錄 |
| TargetDir | 目標輸出文件所在的目錄 |
| TargetExt | 目標輸出的擴展名 |
| TargetFileName | 目標輸出文件名，包括擴展名 |
| TargetName | 目標輸出名，不包括擴展名 |
| TargetPath | 目標輸出文件的全路徑名 |