产品开发平台管理部软件实现专题  第9期
总61期  编号201200711
工程文件配套说明提交的必要性
（软件开发一部施先清）
软件实现流程中编码作业指导书提出：“提交的工程文件，建议可配套提交说明，标注此工程文件是在哪个版本的编译器生成。”这样的一点规范要求，我个人觉得是相当有必要的。
在统一交换平台POTS项目中，我们在开发POTS的DUNE套片和几个OTN芯片的驱动功能时，出现过这样的情况：
1、2011年POTS进行前期开发时，几块硬件单盘都采用了BCM专项组提供8247小扣板。几个核心芯片驱动软件工作是基于VxWorks5.5开发的，在Tornado2.2集成开发环境下进行代码调试，直接使用该开发工具编译我们自己的工程，使用Tornado内嵌的gnu编译器编译SDK，相应的有SDK的编译工程文件；
2、2012年POTS项目开始开发c700和c400设备，各个单盘硬件采用了8308扣板。我们专项组要为这些新盘子开发驱动代码，包括去年已经开发了的DUNE套片和OTN芯片驱动，开发环境是WorkBench，以
前的SDK文件、编译工程、甚至我们自己的代码和工程，都不能在新的环境中顺利编译，需要做大量移植工作：
A）直接将以前的库文件（*.zb或*.a或*.o或*.out）copy过来，不能正常使用：使用*.zb文件自动加载失败，使用*.out文件load不进去，使用*.a或*.o文件连接
时也会报错。
B）直接将以前的原代码文件(*.c和*.h)copy过来，编译通不过，更改编译选项，很多人尝试多次，都没有成功，始终无法编译生成库文件(*.o)。编译器报告错误，
不仅是报警。
C）对报错的源代码进行相应修改后，最终编译通过生成*.o文件，进而得到可以加载的*.out或*.zb文件。由此可见，编译器集成的环境以及版本对代码的语法检查规
则是有差别的，并不完全兼容。换个编译器，极有可能带来代码移植修改工作。
D）对SDK的编译，一般是采用原厂提供的对应的makefile工程进行编译。makefile 会包含一些编译选项，这些选项不仅依赖于操作系统，通常还会依赖于OS的内核
gnu编译器
版本，有时还会和编译器的版本有关。
E）原厂的SDK源代码中经常会使用许多供编译选择的宏，有些宏和OS、OS的版本有关，可能还会和编译器或版本有关。
F）相同的代码，在不同的编译器中编译得到的执行代码，最终的执行结果可能会不一致。我们专项组的毛晓波和宋威在POTS项目中，曾发现过这样的问题：同样的一
行代码，是对两个不同类型的变量比较大小，在8247扣板下得到的结果为1，而
在8308扣板下得到的结果却不为1。这段代码是在SDK中出现的，对于SDK中出
现的不符合标准的代码，就有可能会导致这样的结果。
Tornado和WorkBench都是基于VxWork内核，都内嵌有gnu编译器，只不过版本不同。由此可见，在某些情况下，工程文件是依赖于开发环境的，尤其是编译工具及其版本。所以标注工程文件的编译器，是相当必要的，可以避免编译通不过、无法加载等问题。同时必然会带来很多好处，比如避免因编译器选择不当而带来额外移植工作。
虽然上述案例问题是发生POTS项目中，但我相信该问题可能出现在其他项目中，存在
一定的普遍性。所以在今后的工作中，如大家都能养成良好的工作习惯，在提交的工程文件配套说明中标注工程文件的编译器及其版本，定可一定程度的避免上述问题带来的巨大工作量。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。