与恐龙共舞 2 编译调试

做java的都喜欢eclipse的增量编译 习惯以后再来看C的编译, 觉得慢的不可思议. 希望CDT能彻底一些改变这个问题.

古董项目有个共同的特征, 就是makefile, 这个恐龙里面不但有makefile, 还有ant脚本, 还调用了多种语言写成的脚本...彪悍吧.

所以,每个新人都会情不自禁的用eclipse建立java project, 那要等到话儿都谢了.
不说编译, 从共享目录里面去refresh一下项目都要老半天.
在专用的solaris server上面编译, 大概两三个小时吧. 这里面很多可以改进的地方. but, not now. 先完成任务.

标准做法是建立一个没有编译器的java project, 然后经过漫长的refresh, 这个项目就有了, bin目录下面是solaris编译出来的类.

那么前辈们是怎样调试的呢? 嗯, makefile有个好处, 可以单独编译, 然后把编译后的classpath加入到调试机器的classpath前面, 重启server就该生效了. server加上远程调试选项, 从eclipse里面远程调试.
至少

看到问题没? 单独编译很快, 可是重启很慢, 有多慢呢? 当然要体现出大项目的特点, 慢, 至少几分钟. 所以如果调试一个代码, 可能改几次, unix下面编译, server restart, 客户端操作, 触发eclipse断点. 一上午没改多少代码, 就过去了. 特别是sun workstation, 一个cpu比server综合慢10倍.

这还好了, 以前的前辈们连远程调试都没得玩呢. 都靠log打印的.

慢, eclipse远程调试可以hotswap, 不需要重启的.
错, 因为只能在unix下面编译, eclipse不能自己编译, 所以hot-swap不生效. #$*^(@#

OK, 痛苦了两个月以后, 痛定思痛, 我们能做点什么呢? 而且要小心, 因为一个项目refresh一下都要僵死很久.

这个改进的契机是另外一个项目, 他们的项目之间有依赖问题, 过去别忙看了一下突然想起来最擅长的: 项目依赖!

但是, 项目不能自己编译. OK:
1. 还用原来不能自己编译的太监java项目. 这是base. (连增量编译都没有的java项目,bin下面已经有在unix下面编译好的类.)
2. 把要修改的代码单独checkout出来, 组织成迷你的java项目. 肯定编译不过
3. 迷你项目依赖编译base项目. 编译通过. 这是以前打补丁常玩的办法.
4. 迷你项目自动编译, 远程调试, 自动hotswap改动的代码.

后记:
1. 推广了这个项目组织形式以后, 生产效率大幅提高. 但是我的工资没有提高
2. hotswap不是万金油, 只能替换方法体.
3. 还能改进, 把base项目砍掉, 只依赖其编译生成的jar, 指定jar的source也可以. 但是有些东西编译后是看不到的. 根据情况取舍吧.
4. 有些第三方工具可以实现任意的hotswap, 但是碰到solaris都玩完.