Vs 2008 Solution directory Structure Setup and management

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

This IDE of MS is so complicated and terrifying. Starting from the university, I have been using various versions of the VC to write the program so far, to think carefully, but also just whole, ashamed unceasingly. But if you look at the document carefully and feel that time is not worth it, then you have been using it for life.

The first time is responsible for building a new project development environment, and has been looking at Gamebryo code, from which a lot of engineering management methods. Combined with the previous experience of using VC, now summed up with you to share, hope to play a role.

Project directory Structure

VC uses solutions (solution) to represent projects, each consisting of one or more projects (project), each of which manages a relatively separate module. Some large projects, such as Gamebryo, may even have multiple solution: a solution to manage Lib or DLL, a solution to manage all the demos, a solution to manage tools, and so on. Split into multiple projects, one of the benefits is the structure is clear, and the second is to facilitate parallel development. Each project is maintained by a different programmer, output lib or DLL, and then the link is delivered to the final exe. The split of the project is very technical content, you can see the design of the skill. Poorly split, there are some negative effects such as "project interdependence."

The first thing to consider when building a project is how to configure the file directory structure. If it was a tiny project with just a few obj, it would be all right to throw everything in one directory (which is, of course, the worst), and for a big project with n projects, a lot of source code, documents, resources, and so on, bad file management would make a mess of things. A good directory configuration can help developers quickly find what they need, and it's easy to add new modules and code, even reflecting the project's infrastructure ... Finally, a good directory structure is full of beauty:)

Below is I prefer the directory structure settings, in fact, according to the size of the project and the need to increase or decrease:

SRC: Store all the source code
Build: Store all project documents (Solution,project,makefile, etc.)
Doc: Project documents, Doxygen files, etc.
SDK: All library files and header files that the project relies on
Out: Intermediate files generated by the compiler, target files
Bin: compiled EXE and DLL
Not listed, but usually there are:
Res: Resource directory, executable files need to use a variety of images, sounds, models, scenes, UI and other resource files
Script: Storing Scripts files
Tool: Various automation tools

A little explanation: first, the most important source code to put a separate directory, and the different modules are collocated into different subdirectories. The advantage is that others just need to look at your directory structure, and you probably know what kind of architecture your project is. I hate all the headers to put a directory, all CPP in another directory of the practice, to find a file is very painful.

Second, the project file (VC solution,project,makefile, etc.) put a separate directory. The importance of the project document is second only to the source code, no project files, others to compile or browse your codes are very cup. Plug a sentence, there is VC project, Windows with VC look at the code is really the choice (of course, the tool set under Linux does not have to mention), again is editplus+everything. In other words, if you're a professional, there should be two subdirectories under build: Msvc and Makefile, and of course there are codeblock,codelite and so on. VC Project, Solution,project and property sheet should also be stored separately

Then there is the static library. Each project should be self-sufficient, that is, the entire project directory I copy anywhere, can still compile and run. Therefore, you must include all third-party library files and related header files that are dependent on the project. And our project itself may be output lib, also should be placed in the same directory, so as to facilitate the setting of the search path.

Finally is the compilation process produces intermediate files, these I throw all in the Out directory, press "" Project_Name/[debug | release | shipping]/"sub-directory storage, one is easy to clean, two is looking at Shuxin, Recently I also found that this also avoids the problem of PCH replacing when linking to static libraries. and EXE and DLL I output to the bin, Lib output to the Sdk,debug version with the suffix _d,release version with the suffix _r, similar to shipping version with the suffix _s

The next step is to talk about the settings for the project Properties ...

Solutions and projects: from VC6 the VC series uses solutions (solution) instead of the original workspace for organizing and managing multiple related projects (project). The article first demonstrates a virtual solution and the directory structure that we expect to get, and then uses the VC2008 Project Setup feature to achieve our needs step-after-step. Virtual Solution: This virtual solution, named GMA, contains a dynamic link library project Chocolatemilk and an application project Puremilk, which requires a third-party library Log4cxx (Apache log4j C + + ported version for log output). Log4cxx is compiled in the form of a dynamic library, so we need 3 things for it, namely header files, import libraries (Log4cxx.lib, log4cxxd.lib), and dynamic link libraries (log4cxx.dll). Suppose we expect a directory structure such as: 1.  gma is the solution directory 2.  puremilk and Chocolatemilk are project directory 3. The  lib directory is used to store import libraries or static libraries (including third-party libraries and their own projects) 4.  include header file for storing third-party libraries 5. The  bin directory holds all dynamic link libraries and execution files, including its own outputs and third-party libraries, distinguishing between release and debug two versions. In addition, the process requires external data files and configuration files needed at startup, etc. can be placed in the directory 6.  temp is used to store temporary makefile, where compile holds the obj file generated by the compiler at compile time, and link stores the linker's output file. The above directory structure clear, one side knows, when our program needs to make the installation package or to package the source release, it can make our life easier ^_^ we only need to package all the files in the "/gma/bin/release/" directory when we make the installation package. When we publish and transfer the source code, we can package all the files and directories under "/gma/" except the temp directory (or bin if you do not need to execute the file). Our needs are clear, but VC 2008 does not automatically do for us all the above things. However, we do not need to write a complex compilation script (makefile), simply modify the project's default settings. The things we need VC to do for us include: 1. Use "/gma/temp/compile/" as the intermediate Directory 2 used when compiling the project. Use "/gma/temp/link/" as the output directory for project links 3. When the project is an application, copy the execution file to "/gma/bin/release/" or "/gm" after the build is finished.a/bin/debug/", when the project is a dynamic link library, in addition to copying the DLL to the Bin, also copy the import library to"/gma/lib/"4. When the project is an application, run the Execute file under "/gma/bin/debug/" or "/gma/bin/release/" while debugging, with "/gma/bin/debug/" or "/gma/bin/release/" For working directory First look at the macros that can be used in the project settings, commonly used are:

ConfigurationName	Configuration name, usually debug or release
IntDir	Intermediate directory used by the compiler, output obj file
OutDir	Output directory used by the linker
ProjectDir	Project directory
ProjectName	Project name
SolutionDir	Solution Catalog
TargetDir	directory where the destination output file resides
Targetext	The extension of the target output
TargetFileName	Target output file name, including extension
TargetName	Target output name, not including extension
TargetPath	Full path name of the destination output file

First, set the chocolatemilk:1. Use "/gma/temp/compile/" as the intermediate Directory 2 used when compiling the project. Use "/gma/temp/link/" as the output directory of the project link note the highlighted section, first change the configuration to all configuration, so that we can simultaneously modify the debug and release parts; Output Directory (output directory, linker) field fill in: $ (solutiondir) \temp\link\$ (ProjectName) \$ (configurationname) Intermediate directory (Intermediate directory , compiler) field fill in: $ (solutiondir) \temp\compile\$ (ProjectName) \$ (ConfigurationName) 3. Copy the dynamic link library to "/gma/bin/release/" or "/gma/bin/debug/" at the end of the build, copy the import library to "/gma/lib/" we usually add the letter "D" after the debug version of the output library to indicate that this is the debug version, Under Debug Configuration, modify the Import library field: VC allows us to set the script to execute before and after the build, so in order to complete 3, we need to write the script executed after the build: Fill in command line, Debug config: Copy $ ( TargetPath) $ (solutiondir) \bin\$ (configurationname) \;copy $ (TargetDir) $ (TargetName) D.lib $ (solutiondir) \lib\; Release configuration: Copy $ (TargetPath) $ (solutiondir) \bin\$ (configurationname) \;copy $ (TargetDir) $ (TargetName). Lib $ ( SolutionDir) \lib\; Because the VC does not represent the import library's macro name-_-pok, so far, you can compile Chocolatemilk project test is not all normal, but please confirm that the target directory of the copy is established beforehand. Next we set up the application project puremilk:1. Use "/gma/temp/compile/" as the intermediate Directory 2 used when compiling the project. Use "/gma/temp/link/" as the output directory for project links first change the configuration to all configurations(All configurations), which allows us to simultaneously modify the debug and release parts, output directory (export directories, linker) fields filled in: $ (solutiondir) \temp\link\$ (ProjectName) \$ ( ConfigurationName) Intermediate directory (intermediate directory, compiler) field filled in: $ (solutiondir) \temp\compile\$ (ProjectName) \$ ( ConfigurationName) 3. After the build is finished, copy the execution file to "/gma/bin/release/" or "/gma/bin/debug/" in command line, under all configuration: Copy $ (TargetPath) $ (solutiondir) \bin\$ ( ConfigurationName); 4. Run the execution file under "/gma/bin/debug/" or "/gma/bin/release/" while debugging, and fill in the Working Directory command field with "/gma/bin/debug/" or "/gma/bin/release/": $ ( SolutionDir) \bin\$ (configurationname) \$ (targetfilename) Working directory fields fill in: $ (solutiondir) \bin\$ ( ConfigurationName) \ So it's done, now you can compile the executable and debug it.


Visual C + + uses a solution to manage projects, there may also be dependencies between projects, set up a solution directory structure that works for you, easy Code management, and program publishing.

The following begins a virtual solution design:
Assuming this solution has application project A, dynamic link library project B, static link library project C, where project A depends on project B and Project C, the structure of the solution project is as follows:

The directory structure is as follows:

Bin: Store all dynamic link libraries and executable programs, two versions of debug and release
A: Application project folder
B: Dynamic link Library project folder
C: Static link library project folder
DOC: Storing project documents
Include: The header file that holds the reference library
Lib: An import library, a static link library, that holds a dynamic link library
Temp: Holds temporary makefile, where compile holds intermediate files at compile time, link output file
Other folders do not need to be manually created, except that Doc needs to be built on its own.

Project Structure Creation steps:
1. Create a new application project, name A, the solution name is work, as shown in:

2. In Solution Explorer, right-click on "Solution Work", "add" → "New Project" → "Win32" → "Win32 project", Name B, select "DLL" and "Empty Project" in "Application Settings";
3. Add a "Win32 project" in the same way, name C, select "Static Library" in "Application Settings", remove "precompiled header" option;
4. The project structure is as follows:

Project Property settings

Configuring the properties of Item A
1. Configure "All Configurations", "General",
Output directory: $ (solutiondir) temp\link\$ (ProjectName) \$ (ConfigurationName)
Intermediate Directory: $ (solutiondir) temp\compile\$ (ProjectName) \$ (ConfigurationName)

2. "Generate events" → "post-build Events",
Command line: Echo D | xcopy "$ (TargetPath)" "$ (SolutionDir) bin\$ (configurationname)"/y
3. "C + +" → "General",
Additional Include Directories: $ (solutiondir) include
4. "linker" → "General",
Additional Library Directories: $ (solutiondir) Lib
5. "Commissioning",
Command: $ (solutiondir) bin\$ (configurationname) \$ (TargetFileName)
Working directory: $ (solutiondir) bin\$ (ConfigurationName)

Configure the properties of item B
1. Configure "All Configurations", under "general",
Output directory: $ (solutiondir) temp\link\$ (ProjectName) \$ (ConfigurationName)
Intermediate Directory: $ (solutiondir) temp\compile\$ (ProjectName) \$ (ConfigurationName)
2. Configure "Debug", "linker" → "General",
Output file: $ (SolutionDir) temp\link\$ (ProjectName) \$ (configurationname) \$ (ProjectName) D.dll
3. Configure "All Configurations", "Build Events" → "post-build Events",
Command line:
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
The third behavior xcopy Dynamic Library header file, the actual need to make changes to the name.

Configuring the properties of item C
1. Configure "All Configurations", under "general",
Output directory: $ (solutiondir) temp\link\$ (ProjectName) \$ (ConfigurationName)
Intermediate Directory: $ (solutiondir) temp\compile\$ (ProjectName) \$ (ConfigurationName)
2. Configure "Debug", "Administrator" → "General",
Output file: $ (SolutionDir) temp\link\$ (ProjectName) \$ (configurationname) \$ (ProjectName) d.lib
3. Configure "All Configurations", "Build Events" → "post-build Events",
Command line:
echo D | xcopy "$ (TargetPath)" "$ (SolutionDir) Lib"/y
echo D | xcopy "$ (projectdir) C.h" "$ (SolutionDir) Include"/y
The second behavior xcopy Static library header file, actually want to change the name according to the need.

Finally set the project build order
menu bar → project → project dependencies, project a relies on B and C as shown in:

Compile the build, you can see the following results:

Look at the folder structure with the tree command:

Other online about directory structure configuration information:
Directory structure setup and management for 1.VC 2005 Solutions http://blog.csdn.net/rogeryi/article/details/1481923
2.VC Project Management: directory Structure http://www.fancystar.org
Management of VC project Files directory in 3.vs2008 http://qimo601.iteye.com/blog/1059299
4. Research and Development Code-VC http://wenku.baidu.com/view/26f6c789680203d8ce2f2414.html

Vs 2008 Solution directory Structure setup and management (RPM)