Andrew Huang
带学生移植大量程序，也在实际项目应用其管理规范。因此将其定名为bluedrum linux 移植规范.
这个规范的有如下几个要点,它合适个人开发，或小团队（即无固定的中心服务器）的开发。
理论上可以合适大团队开发，但需要在实践开发
1.移植项目要有一个总的项目目录,这个目录必须在NFS发布目录,
最好也是Samba和FTP发布目录.
我建议的做法是创建一个workspace用户,创建在/home/workspace目录，这个目录被发布成NFS/Samba/FTP共享目录。每一个项目都建在/home/workspace之下。
优点：编辑，编译在HOST上运行，嵌入式LINUX程序通过NFS直接运行.
如果习惯用Windows下工具来管理(beyend Compare/Source Insight)源码.
所以一般我建议学员，在自己的机器一安装好，立马建一个自己用户名目录，比如我的就是固定会建好/home/hxy,全部设成各种共享目录。为了减少权限上的麻烦，最好把权限全打开
chmod -R 777 /home/hxy
2.所有输出文件（编译出来库，头文件，可执行文件,测试数据）将集中输出项目目录 output/
比如 arm-linux输出到 output/arm-linux
按OS来区别主要考虑到一个项目很多情况要在多个平台编译比如 x86-linux,mips-linux或者wince,windows
按个OS分开，在项目开发时各不同版本交替使用时，大家互不干扰 。
另外在小团队下开发，开发人员只需要把output打包交给测试人员即可进行测试，无需把整个源码交给对方，这样方便管理.
3.第三方库要在项目目录下libs解开编译
这样设计是一是防止库太多把自己的项目主程序源码淹没。
第二个是可以在不同项目目录简单复杂重用即可。或者在简单同一类的小项目可以归并到一个目录下
4.主控应用单独在项目目录
主要是为了编译和调试方便
5.在项目目录下可以建其它辅助目录
docs/
还有一个是si_prj.即source insight 的项目文件目录。（注意新建好SI项目后，要打一个包备份，因为SI的项目文件在Samba路径上不正常关闭，很容易崩溃。崩溃后简单解压备份即可)
6.小团队的源码控制最合适的系统是git。
它不需要专门中心服务器。 它会项目目录下建立.git目录
7.在Windows下源码路径管理
如果把整个源码迁移到Windows目录， 需要调用subst命令把项目目录映射虚拟盘符
如果是Samba目录下，可以直接映射Samba为WINDOWS的一个虚拟盘符。
这个在移动环境下优为重要，因为你用移动硬盘接在不同设备运行虚拟机，必然会导致映射的盘符不一样。通过这个办法，可以始终保持盘符不变，这样WINDOWS下工具比如SI就会保持不会移动
采用固定的项目结构，可以在以后的项目中最大程度减少管理上或移植上问题，另外在多人开发时，相同的结构可以在交流和沟通上减少麻烦。
这一系列下的所有文章都是用如下结构来构造的。因此只要这个规范，大部分的脚本的编译可以直接使用
实际工程样例:
以比较简单的Madplayer为例可按如下目录结构建立
/home/hxy
|
+-- madplayer
|
+-- docs
|
+-- si_prj
|
+-- libs
| |
| +-- libid3tag
| |
| +-- libmad
|
+-- madplayer
|
+-- output
|
+--arm-linux --+ -- bin
|
+ -- lib
|
+ -- include
|
+ -- share
阅读(1754) | 评论(0) | 转发(0) |
