关于在美拓的简短的总结与体会 (2).docVIP

关于在美拓的简短的总结与体会 概要： 这仅仅是个人的一点心得体会与总结，本登不得大雅之堂，然而我作为一个对于手机开发完全的零起点对于其中的艰难与痛苦有着切肤的体会，这一切促使我不敢身藏浅陋将一些零星琐碎公之于众，即作为自己在美拓的简短人生经历的一个总结，如果能给后来者提供一点点地借鉴也心满意足了。 关于编译环境的认识体会 首先面对程序员的就是相对复杂的编译环境及其繁琐的配置工作。高通平台分为仿真和实际的arm编译两个截然不同的编译环境，其中有些相同有些不兼容。 a) 仿真编译 仿真完全使用vc6的编译机制，高通的例子是把一个个小applet编译成为dll动态库，我们的工程应该是把brew的模拟器作为静态库链接到meta的工程里面，模拟器的配置在win32/bin/brew_emu.dat中，在其中可以指定外观即devicepack配置文件，以及applet运行的文件系统路径，及其相应的mif文件所在路径。 PhoneFile=H:\CDMA\L200\Win32\DevicePack1\L200\DevicePack1.dpk AppletDir=H:\CDMA\L600-new\Resource\FileSystem MIFDir=H:\CDMA\L600-new\Resource\FileSystem Vc6能够自动解析源文件的相应的依赖关系省却了程序员写makefile的痛苦，但是如何创建vc6的工程文件是一个很繁琐的工作。 美拓的代码统统使用cfg文件管理机制可以很方便地依靠gendsp.cmd工具加入工程组，也就是说每个源代码模块都定义了一个.cfg文件，里面列明了模块的头文件.h，源文件.c/.cpp，以及链接库.lib/.a。 [IncludeFiles] $(METAMMI)/apps/Java/jblendia_jvm/include/settings/Meta_Java_Settings.h [SourceFiles] $(METAMMI)/apps/Java/jblendia_jvm/port/amsui/Meta_AmsUI.c [LinkFiles] !ifeq ($(META_TARGET),Arm) $(METAMMI)/3Parts/JBlend/library/ajsc/ajsc_arm_ads.a !else $(METAMMI)/3Parts/JBlend/library/ajsc/ajsc_win32_msvc.lib 以上就是.cfg文件的格式，于是，运行win32/build目录下的gendsp.cmd就会运行一个perl的脚本gencfgmin.pl来读取metammi.cfg文件，这个文件列表了所有工程要包含的meta的模块cfg文件，然后通过这些cfg文件列明的.h,.c,.lib文件就被加入了工程，也就是加入了simulator.dsp的vc6的工程文件。 但是代码里面的include头文件是一个很麻烦的事情，首先，有些工程人员喜欢把其中的头文件名前面加上相对的路径，但是这个对于编译确实很麻烦的事情，因为编译器寻找这些路径是从一个运行的相对路径开始，然后按照编译设定的搜索路径和系统环境变量比如/include项下的路径搜索，一旦工程文件位置变动就有可能搜索不到，同时过多的设定搜索路径会减慢编译速度，因为编译器会不停在各个路径下搜索，而在系统环境变量中设置弊端更多因为有可能把不同项目的同名头文件包含进来，这才是程序员的噩梦。因此美拓的做法是include统统使用双引号并且不带路径，并在遍历.cfg的时候把这些相应的头文件都拷贝到win32/build/include目录下，所以，你在vc6的工程里面看到的头文件在编译器看来却是在使用另外一个在build/include目录下的同名头文件，你要改动必须修改工程原路径下的重新编译才能更新拷贝，否则修改build/include下的拷贝都被覆盖掉了。 cfg机制对于非高通的meta的代码很方便，但是高通是采用一个min文件的方式来建立makefile的，添加到vc6工程就没有那么方便了，幸好不是很经常修改高通代码，因此，我们可以在simulator.dsp的源头template.dsp里面修改，就是把需要应用的高通的.c文件加到template.dsp文件里面，运行gendsp.cmd就更新了simlator.dsp。但是头文件是不能拷贝进来的，只能使用vc6的头文件搜索路径添加：ADD BASE CPP /nologo /MD /W3 /GX /O2 /I ..\..\binstore 这里的/I就是搜索头文件的路径，头文件的名字自然是在代码里面的了。 链接的链接库也是类似的使用# ADD LINK32 libjpeg_win3