代码改变世界

shit!Vxworks!Shit!WorkBench!

2010-12-03 19:04  Jeff  阅读(1595)  评论(0编辑  收藏  举报
郁闷的一周,一周的郁闷! Fuck the Vxworks! Fuck the WorkBench! 终于在注释掉报错的几行代码后,不管三七二十一,先编译通过了.但是走到这一步,弯路走了不少. 记录下来,以儆效尤!下周再解决这几个编译错误,抑或是不解决? 1. 安装workbench 3.2的时候没有使用同一目录下的licence,安装不成功.安装成功后,用开发组给的2个label竟然想编译! 2. 拿到了一个config spec!然后是按照Vxworks 6.5的方法在Vxworks6.8环境下编译,结果报错.于是删掉project文件,结果删除project文件的时候,选择了同时删除workspace下的文件(脑子进水了!),但是workspace下文件是在clearcase里的。于是在下次import project的时候,出现了project无法编译的现象,其实是check out的project文件被删除了。于是在clear case里只能看到这个被check out了,但是找不到这个文件!更搞笑的是,当天从同事那里得知信息,这个应该是clearcase的问题,找CM解决。 3. 周末加班,在热心同事的帮助下,才意识到是check out的文件被删除了(其实自己已经意识到了,奶奶的,这个现象和unix下clearcase的现象是一样的啊,cleartool ls 是看不到这个文件的)。回复的方法:先创建同名的文件,然后uncheckout,然后再checkout. 4. 紧接着遇到的问题是编译项目的时候,一会儿会报一个license 的fatal error.以及一个VSB project的警告.只好发了一封信给有经验的同事,回家. 5. 同事告知是license的错误,并且给了一个正确的license的路径,放在环境变量里,重启电脑这个问题搞定. 6. 在使用Vxworks6.5方法还是编译不过的情况下,决定先编译目前项目A的dependency项目B.项目B恶搞了好久,还是编不过.随后从同事出得知是config spec的问题,之前给的config spec不对! 7. 拿到新的config spec之后还是编译不过!从错误中,编译通过的同事告知编译项目A checkout的一个文件在编译项目B的时候不应该check out!这个编译项目B大概需要3-4个小时,于是决定默认项目B已经编译通过,毕竟要3-4小时啊。而且自己使用的config spec和同事使用的完全一样,他们已经编译通过了,无需再浪费时间。 8. 于是再次把项目A的config spec加入到项目B的config spec中去,还是无法编译通过! 9. 意识到.wpj文件需要从Vxworks6.5 migrate到Vxworks 6.8. 使用workbench的 CLI命令搞定. 生产的kernel configuration有问题,需要在workbench中纠正这一错误。 10. 编译还有问题,随后咨询有经验同事,告诉我link文件有问题!于是把link文件改成Vxworks6.8上的,从其他project拷贝过来即可. 11. 编译错误变成无法识别inline函数.新版本inline函数是从其他的目录移过来的.这个inline函数用的还是K&R风格,参数类型的声明是在函数名字下面的,括号外面.如果改成非inline,非K&R吧,项目C编译不过,否则项目A不过 12. 挣扎良久之后,决定这2个文件用以前版本的。则这个问题解决了.这是因为项目A这样不再包含inline函数的代码。 13. 随后的一个问题,还是觉得是inline的问题,Undefined symbol.4个Undefined symbol的问题. 把这4个问题注释掉以后.勉强能编译出.hex文件. 悲剧啊!开发的任务还没有开始!环境的问题还没有解决!这个编译的问题不知道是否是地雷! 1. 重来没有用C/C++做过项目 2. 压根一点儿都不熟悉workbench 3. 对整个系统不熟悉,不了解各个子系统各自功能 4. Vxworks知识一点都无 5. 对源代码一知半解!