工程目录结构模板设计

需求:

* 文件和工程的良好组织，可以使工程维护者按照自然思维快速找到需要的资料和工程，工程目录结构要自然清晰。

* 如果此工程目录中的资料，子工程增加时，资料的存储结构还能保持清晰有条理.

 

* 针对c和c++的工程，我前段时间调整过2次，最近觉得工程目录结构不太合理，重新调整一下。

  1. 想把UML和MindMap的工程也放到工程目录中, 作为工程原始资料和文档进行存储.

  2. 在多次工程实践后，发现以前有些预设的工程目录基本没有用到.

  3. 在实际工程应用中，发现要操作的inc目录, lib目录和原始工程的深度差太多(3层, 基本都需要写上../../../inc/), 很不方便.

 

* 整理后的效果想要Linux下的那种一目了然的目录结构, 简洁，清晰.

./readme.txt/工程目录结构模板设计_2011_0309_2054├─document 设计文档│ ├─change-log 程序维护历史│ ├─mind-map 思维导图设计文档, 工程│ ├─picture 为维护者, 最终用户, 设计文档准备的图片│ └─uml UML设计文档, 工程└─program ├─bin 所有程序的输出目录(.obj, .exe, .ocx, ...), 每个工程的编译文件(.obj)有自己的子目录 ├─common 子工程之间公用的实现文件(.cpp, .c, .h, .hpp) ├─inc 工程需要包含的头文件, 可以有子目录 ├─lib 工程需要包含的库文件, 可以有子目录 ├─mainprog 主工程 ├─reference 参考工程, 工程结束时按照实际情况决定是删除或保留 ├─resource 工程中要包含的资源文件(.msstyles, .bmp, .png, .jpg, .gif, ...) ├─temporary 临时目录, 工程结束时必须删除目录中的内容 ├─testcase 针对主工程应用的独立测试程序和预研Demo, 工程结束必须保留 └─third-party 程序中用到的第三方库的源工程. 如果需要进行修改, 修改后的工程应移动到mainprog中

 

 

先修改成这样，用一段时间再说.