Tony Bai

对于我个人来说，将工作环境切换到Ubuntu上来有几个“坎儿”要迈过，其中最为迫切的一个就是Mail如何在Windows和Linux下共享的问题，今天我找到了解决方法。

Thunderbird和Firefox一样，都来自Mozilla组织。和Outlook等软件不同的是，Thunderbird是可以跨平台的，更有甚者，Thunderbird可以帮助我们在Windows和Linux共享邮件，当然需要作简单设置。

我的机器上安装了三系统：WinXP、Ubuntu 9.10和Slax，其中常用的是WinXP和Ubuntu。在Windows上最常用的Mail Client端软件为Outlook 2003，但Outlook是收费软件，不支持夸平台，更谈不上Mail跨平台共享。而这些恰恰是Thunderbird吸引眼球之所在。

所谓的跨平台共享邮件是指计算机上只存储一份Mail Data，而你在该计算机上所安装的不同OS上都有某个特定应用可以正确存取该数据文件，这样带来的方便是很大的。Thunderbird就是这样的一个特定应用，它可以被安装在不同的OS上，并且可以在不同OS上运行并正确存取同一份Mail Data文件。

以我自己的本子为例，记录一下如何进行共享邮件设置：
首先，分别在Windows和Ubuntu下面下载并安装最新中文版本的Thunderbird(目前是2.0.0.23)。
在某个OS上运行并配置Thunderbird，这里我是在Windows上进行配置的。这里有一个注意事项，那就是你的mail数据的存储位置的选择。在“帐号配置”的“服务器”配置标签中，找到“本地目录”配置项，这个配置项将决定了Thunderbird将Mail Data存储在什么位置。如果你要在Windows和Ubuntu之间共享这个Mail Data，那么就需要让Windows和Ubuntu都能看得到、访问得到这个文件。我这里选择在一个FAT32分区上存储Mail数据。

配置完Mail帐户，Thunderbird默认会在C:\Documents and Settings\[username]\Application Data\Thunderbird\Profiles\xxxxxxxx.default中存储该帐户的配置信息。为了能在两个OS间共享Mail Data，我们就需要让这个配置在两个OS上都能发挥作用。

我们将该配置文件移动到一个FAT32分区上，比如这里以E:\Thunderbird_profile为例，将xxxxxxxx.default移动到E:\Thunderbird_profile目录下。这时你要是启动Thunderbird，那么Thunderbird就无法找到该配置文件了。但是我们需要Thunderbird找到并读取该配置文件，怎么做呢？我们需要修改另外一个文件，在Windows上这个文件就是C:\Documents and Settings\[username]\Application Data\Thunderbird\profiles.ini。

初始的profiles.ini文件内容如下：
[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=1
Path=/Profiles/xxxxxxxx.default

其中IsRelative用来指示Path这个字段配置的是相对路径还是绝对路径，默认是相对路径。由于我们已经将配置数据移动到E:\Thunderbird_profile目录下了，那么我们就不能在使用相对路径了。修改结果如下：
[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=0
Path=E:\Thunderbird_profile\xxxxxxxxx.default

启动Windows上的Thunderbird，该配置被正确读取，收发Mail正常。

切换到Ubuntu下面，同样道理，你需要修改profiles.ini文件，该文件在~/.mozilla-thunderbird下面，修改方式与Windows上相同。不同的是Path字段要配置成Linux格式的路径。

启动Ubuntu下的Thunderbird，哇，一切与Windows上的Thunderbird一模一样。你可以看到全部的在Windows上收到和发送出去的那些邮件。

共享Mail设置成功！

Ubuntu 9.10版本在10月29日发布，虽然没有太多吸引我的地方，但是看了网上很多关于Ubuntu 9.10的文章后，心里面还是痒痒的，终于在上周五我用午间休息时间完成了Ubuntu 9.10版本的安装。

光盘是让同事帮我下载并刻录的，安装过程和以前没什么两样，由于本本中已经有了9.04版本，直接插入光盘升级安装就可以了。大约40分钟后，安装完毕，重启进入Ubuntu 9.10。首先感受到的变化就是Ubuntu的启动和登录界面了，黑白鲜明的反色对比的登录界面显得更科幻，启动速度较快，比起我的Windows要快上太多。

由于导入了9.04的用户数据，所以省去了很多工作。但是更新源、安装中文语言支持是必不可少的。这些工作都结束后突然觉得这个9.10安装后屏幕上的中英文字体看起来都很别扭，不舒服；使用9.04版本时我也使用的是默认字体，但是却没有这么别扭的感觉，遂尝试更换字体。在桌面右键“更改桌面背景”->"字体"中看到当前使用的字体都是"WenQuanYi Bitmap Song"，然后到网上查了一下，发现用文泉驿微米黑的人不少，我也下载了一份(sudo apt-get install ttf-wqy-microhei)并配置了系统字体以及Firefox的字体，果然界面顿显漂亮多了，以后也就是它了:)。

以往每每安装Ubuntu后都要自行安装中文输入法软件，但这次不用，Ubuntu 9.10默认自带了一款称为IBus的输入法框架。之所以称为框架是因为它不仅仅支持中文，还支持世界上其他重要的语言。Ctrl+Space键唤起IBus，尝试在文档中输入中文，发现这个IBus输入法怎么好似十多年前的全拼输入法呢？只能一个字一个字的输入，没有智能联想和光标跟随提示，不能进行词输入和长句输入，太落伍了。但是为什么网上很多人还声称有了IBus就可以不用以前的SCIM和fcitx了呢？难道我还没有挖掘出IBus真正强大的功能所在？经Google的帮忙，我终于明白了原因：原来Ubuntu 9.10默认启动的IBus的中文输入法都不怎么好用，你需要自己重新在IBus设置中添加。选择“系统”->“首选项”->"IBus设置",打开"IBus首先项"对话框，选择“输入法”标签，在“选择输入法”下拉框中找到“汉语”，在"汉语"后面的可选择输入法中选择"拼PinYin"，这才是我们需要的中文输入法。另外默认的IBus的光标跟随提示框是竖向的，你也可以在IBus设置中修改之，改为于Windows下输入法一致的“横向”提示。

Ubuntu 9.10还提供了"软件中心"对系统中的软件进行更好的管理，不过我目前还是习惯使用apt工具。Ubuntu One是9.10提供的Ubuntu云存储的一个客户端，不过不知为何我的机器上的Ubuntu One一启动就报错，另外通过Web页面访问的Ubuntu One目前还很慢，这是我在公司和家里测试的结果。

其他的，还待使用中继续挖掘。

ReviewBoard安装成功至今已半月有余，这期间我一直在试用它，虽欣喜于其提供的强大的功能，但还是有若干使用中的问题一直让我头痛不已，同时也阻碍了在部门推广该工具的进程。

首当其冲的就是对中文的支持问题。按照默认的步骤安装和配置后， 输入和保存英文均没有问题，但是一旦输入中文，保存后页面显示的都是乱码，甚至某些时候在保存中文数据时ReviewBoard还提示错误。我的 Ubuntu的locale是"zh_CN.UTF-8"，输入法输入后的中文内码应该是UTF-8。ReviewBoard本身按理来说其内核也应该是 内置支持的UTF-8编码的，问题出在哪呢？答案是MySQL。

在命令行模式进入MySQL，敲入status命令:
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    latin1
Conn.  characterset:    latin1

我 们看到MySQL当前的四大字符集默认都是latin1，而创建reviewboard数据库时使用的语句又没有指定编码，这样一来 reviewboard数据库和其中表的编码应该都是按照MySQL默认字符集编码(即latin1)创建的，这应该就是中文乱码的根源吧。

修改MySQL默认字符集的方法很简单，先停止MySQL Server(sudo /etc/init.d/mysql stop)，之后打开/etc/mysql/my.cnf，分别在[client]和[mysqld]两个section下，增加一个key-value pair: default-character-set = utf8，保存后退出。启动MySQL(sudo /etc/init.d/mysql start)，用status命令查看，你会看到所有characterset都已经变成了utf-8:
Server characterset:    utf8
Db     characterset:    utf8
Client characterset:    utf8
Conn.  characterset:    utf8

但是这个设置对已经创建完的reviewboard数据库和相关表不会起作用。由于对MySQL不甚熟悉，所以没有尝试去转数据库和表的编码，而是尝试重新创建一套库。这次在创建库的时候为了以防万一，我加上了显式的字符集编码要求。

mysql> create database reviewboard_utf8 default charset utf8 collate utf8_general_ci;
mysql> grant all on reviewboard_utf8.* to 'reviewboard'@'localhost';  /* 前一个reviewboard_utf8是新建的数据库的名字，后一个reviewboard则是之前创建的访问数据库的用户名 */
Query OK, 0 rows affected (0.00 sec)
mysql> exit

数据库reviewboard_utf8默认是utf8编码，则系统默认其中创建的表也都是utf8编码。下面的问题就是如何将ReviewBoard与新库reviewboard_utf8连接起来的问题了。以下步骤供参考:
1、sudo vi /var/www/reviewboard/conf/settings_local.py，修改其中的DATABASE_NAME为reviewboard_utf8;
2、sudo rb-site upgrade /var/www/reviewboard，这个步骤中rb-site会在新库reviewboard_utf8中重新创建ReviewBoard需要的各个表
3、重启apache2 server，sudo /etc/init.d/apache2 restart

当 你再次打开ReviewBoard的首页面时，你会发现一切从头开始了。上面的"换库"操作中，rb-site只是创建了新表，表里并未有任何数据，这与 首次安装ReviewBoard时rb-site帮你创建了一个超级用户是不同的。所以我们这里需要手动做这件事。首先通过页面Register一个帐 户，比如就叫做admin吧。创建后用admin帐户登入，你会发现页面右上方的缺少了'Admin'这个链接选项，你无法通过'admin'用户对 ReviewBoard进行设置，也无法设置用户的权限。这里就需要在数据库中作些手脚了:

mysql> use reviewboard_utf8;
mysql> update auth_user set is_staff = 1 where username = 'admin';

这里is_staff的值决定该用户是否有权限对ReviewBoard站点进行设置。你再刷新一下页面，就会发现右上方出现了一个‘Admin'的链接了。做了上面的工作后，我们尝试在各个页面输入中文并保存，这次中文保存和显示都变得正常了。

在使用ReviewBoard过程中的第二个"问题"其实严格来说是我们自己的问题。我们已有的代码都是在Unix GBK环境下开发的，所有源代码文件都是以GBK编码格式存储的。这样一来一旦你提交了这些源文件的diff，在ReviewBoard中'View Diff'时看到的中文全是乱码，更严重的是某些时候ReviewBoard显示的代码差异的位置与真实代码修改的位置不符。比如我在第1000行 增加了一行: i += 1; 提交diff后，ReviewBoard显示的第1000行根本不是i += 1这行代码，而是之前的若干行甚至是十几行、几十行。我怀疑是我们源代码文件的GBK编码导致ReviewBoard判断出现了错误。我尝试将源码重新以 UTF-8格式保存了一下，并重复上面的修改，提交diff，这回ReviewBoard的View Diff则完全正确，源码文件中的中文注释显示的也很正常。

再有一点就是ReviewBoard的Mail通知设置问题，公司采用SSL 加密mail，ReviewBoard仅支持TSL，在网上查了一下这两个协议应该是可以兼容的，但是设置后就是无法将mail发送出去。突然想起来公司 似乎还发布了一个数字证书 for mail client端使用，也许可能是这个原因导致ReviewBoard无法发送Mail，还待继续研究^_^。

在'IDEAL Garden'上看到作者在文章中提到一个名为Vimperator的FireFox插件，该插件功能甚是强大，可以让你以Vim的操作方式来使用Firefox，对于我这个天天都用Vim写代码的人来说，Vimperator可谓有非凡的吸引力，它可以让你的手指留在键盘上。

安装Vimperator这个插件仅需十几秒的时间，重启Firefox后你就可以以Vim的操作方式来尽情操作Firefox了。重启Firefox后，Vimperator会自动打开其Tutorial页面(你也可以通过在命令行输入'help tutorial'打开tutorial页面)。Tutorial页面介绍了Vimperator的大多数基本命令，熟练掌握了这些命令你就可以自由操控Firefox了。

Vimperator默认会隐藏Firefox的菜单栏和工具栏，你可以通过输入'set go+=mTB<CR>'恢复菜单栏和工具栏的显示。

Vimperator与Vim一样，提供常用的normal模式和command-line模式，通过':'或'ESC’可以在两种模式间切换。

打开一个新网页，可以在command-line模式下输入open(或o)，加上url来打开网页。同样你也可以输入o加上你要搜索的关键词，敲击回车后会自动打开默认的搜索引擎搜索该关键字，就和你用Google ToolBar是一样的。当然在command-line模式下输入open这种方式也支持自动补齐功能，输入若干个关键字后，敲击TAB键，会出现一个下拉列表，之后可继续用TAB键在列表中做选择。另外使用tabopen(或t)则是在新标签页中打开你要的网页。

当你在各个Tab间切换时，命令行中显示的是该页面的url地址，如果你想复制这个地址，只需在normal mode下敲击"yy"，该地址就被写入剪贴板了。

在Tab之间切换你大可依然使用ctrl+tab的方式，但是你同样可以在normal模式下通过gt或gT来前后切换标签页。关闭一个标签页你只需要在normal模式下敲入d即可。在当前页面中后退到历史页用ctrl+o，前进到下一页用ctrl+i。

打开页面中的超链接，你大可以继续用mouse点击；但是vimperator也给你提供了一种方法。在normal模式下敲入:f或F，页面上的超链接将被编号，快速输入你要跳转的超链接的编号，即可打开那个超链接。如果超链接较多，你在输入f或F后输入的字符将被用来做匹配，Vimperator会根据匹配到的超链接文字做编号重分配，减少编号个数，便于你精确定位你想打开的链接。

有了好工具，剩下的就是多多练习、熟练掌握并提升效率了。

目前部门还没有采用Pair Programming那种时时刻刻都在review代码的工作方式，代码Review多采用走查方式，即代码写完后召开一个Code Review的Meeting，集中时间和经验丰富的人力对重点代码进行筛查，这种方式的代码Review有利，但也有弊。其弊端在于低效和覆盖面小。做一次走查需要N多人参与若干个小时，而在这段时间里不是每个参与者都能极其高效的参与到走查中的，实践证明只有少数几个人能真正在一次代码走查会议上起到关键的作用。另外走查一次能覆盖的代码范围又较小，一些看似不重要却很可能带来BUG的代码在走查会上很容易被遗漏。

Code Review工具对代码走查是一种很好的补充。目前比较流行的开源Code Review工具有Review Board、CodeStriker等。对于ReviewBoard，我关注已久。在其还在rc阶段我就曾经尝试安装过，不过无论是在Windows和Unix下都以失败告终。开源工具的安装的确有些让人头痛，一堆互相依赖的软件包，版本稍有差异就很可能导致安装运行失败。而且失败的原因还很难得知。

ReviewBoard今年终于Release了，目前最新版是1.0.3，其官方推荐在Linux和Windows上安装。我选择了Ubuntu 9.04。Ubuntu的包管理工具apt最大的好处就是能自动帮你分析开源包的依赖关系并自动下载安装依赖包。恰巧在CSDN的一个博客上发现一篇'ReviewBoard on Ubuntu 9.04 Server'的安装步骤，我就按照文章中的步骤超级顺利的完成了ReviewBoard的安装，这里我也将其步骤贴出来，并做一些简单注释（有些地方略有不同）：

我是在Ubuntu 9.04 Desktop上安装的，这个版本默认自带Gcc、Python等软件包。我们只需安装其他工具：(如果你是通过公司代理上外网，别忘了在你的Shell配置文件中设置http_proxy环境变量，格式是：export http_proxy=http://user:passwd@url:port)
1、安装easy_install
sudo apt-get install python-setuptools python-dev;

2、安装apache2和mod_python
sudo apt-get install apache2 libapache2-mod-python
sudo a2enmod python /* 修改apache2的配置，让python mod处于enable状态 */

3、安装mysql
sudo apt-get install mysql-server python-mysqldb libmemcache-dev
sudo easy_install http://gijsbert.org/downloads/cmemcache/cmemcache-0.95.tar.bz2

创建数据库、数据库用户for ReviewBoard(这块要注意数据库的字符集设置，默认是UTF-8，如果你要用其他中文字符编码标准，这里就需要显式指定，查查mysql的Manual吧)
mysql -u root -p  /* 用root用户登录 */
mysql> create database reviewboard;
Query OK, 1 row affected (0.00 sec)
mysql> create user 'reviewboard'@'localhost' identified by 'reviewboard';  /* 前一个reviewboard是访问数据库的用户名，后一个reviewboard是密码 */
Query OK, 0 rows affected (0.00 sec)
mysql> grant all on reviewboard.* to 'reviewboard'@'localhost';  /* 前一个reviewboard是数据库的名字，而后一个reviewboard则是访问数据库的用户名 */
Query OK, 0 rows affected (0.00 sec)
mysql> exit

4、安装subversion （目前大多数公司都用subversion）
sudo apt-get install patch subversion python-svn

5、安装reviewboard
sudo easy_install reviewboard

6、创建你的reviewboard站点
sudo rb-site install /var/www/reviewboard   /* 之后会有一系列类似安装向导的步骤，需要你做出选择，尽量选择默认值吧 */
    · Domain = localhost
    · Root Path = /
    · Media URL = media/
    · Database Type = mysql
    · Database Name = reviewboard
    · Database server = localhost
    · Database username = 'reviewboard'
    · Database password = 'reviewboard'
    · Cache Type = memcache
    · Memcache Server = memcached://localhost:11211/
    · Webserver = apache
    · Python loader = modpython

7、配置站点，启动Apache2
sudo chown -R www-data /var/www/reviewboard/htdocs/media/uploaded /* 让webserver拥有对uploaded目录的修改权限 */
sudo cp /var/www/reviewboard/conf/apache-modpython.conf /etc/apache2/sites-available/reviewboard
sudo a2dissite default
sudo a2ensite reviewboard
sudo /etc/init.d/apache2 restart

在你的浏览器里敲入：http://localhost:80，ReviewBoard的登录界面就会出现在你的面前。

顺利安装完ReviewBoard后，你可以到官网去看Manual，学习如何使用ReviewBoard。简单说ReviewBoard支持两种Review Code的模式，一种是在code没有commit之前提交diff/patch文件进行review，叫做pre-commit review，另外一种则是在code commit之后，由工具自动根据提交的版本号生成diff/patch文件，并形成一条新的Review Request，这种模式也叫post-commit review。

先说pre-commit review模式。生成pre-commit review request有两种方法，第一种就是通过页面手工提交patch/diff文件的方法：首先通过界面设置好你的svn repository，比如：svn://10.1.1.23:3344；然后在你的DashBoard中“New Review Request"，有三个字段需要你填写：
Repository:  /* 选择你刚才配置的repository的id */   
Base Diff Path: /* 如果你checkout出来的proj的svn url是svn://10.1.1.23:3344/trunk/testproj，那么这个字段填的就是/trunk/testproj */
Diff: /* 你生成的diff文件的路径，在Windows上我用TortoiseSVN的creatpatch工具直接生成某个源文件的diff格式文件 */

填好后，提交，这时你就会看到一个处于draft状态的Request，继续编辑它，指定Reviewer，然后Publish这个Request，这样你指定的Reviewer就能看到这个Request了。这块如果你设置了Email通知，Publish过程会有一定延迟，特别是如果你的Email设置出错了，那Publish将一直处于ing状态，你刷新一下页面后，实际上你的Request已经publish结束了。

另外一种提交pre-commit review request的方法是通过一个名为'Post-Review'的python脚本实现的。这个脚本在RBTools工具包中，在使用之前先执行：'sudo easy_install -U RBTools'安装这一脚本。

Post-Review需要知道两类信息，一个是ReviewBoard Server的信息, 一个是你的svn repository的信息，第一种信息我们可以通过编辑~/.reviewboardrc，添加一行REVIEWBOARD_URL="http://localhost:80"。至于svn repository的信息，post-review脚本可自动从你本地checkout出的代码working copy中携带的repository信息中获得，前提你要进入到该working copy所在的目录下去执行post-review。比如：你将svn://10.1.1.23:3344/trunk/testproj checkout到~/proj/testproj下面，那么你就应该先cd ~/proj/testproj后再执行post-review，post-review工具在默认情况下会将当前本地代码uncommitted的changes形成一个review request并提交到reviewboard server。你也可以在post-review后面加上文件名字来指定将特定的文件的changes而不是当前项目目录下所有的uncommitted changes。

下面是我配置和执行Post-review出现的一些问题和解决方法:

首次在testproj下执行'sudo post-review'，出现如下打印日志：

Traceback (most recent call last):
  File "/usr/local/bin/post-review", line 5, in <module>
    pkg_resources.run_script('RBTools==0.2beta1', 'post-review')
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 448, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 1166, in run_script
    execfile(script_filename, namespace, namespace)
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 2314, in <module>
    main(sys.argv[1:])
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 2292, in main
    server.login()
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 308, in login
    'password': password,
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 570, in api_post
    return self.process_json(self.http_post(path, fields, files))
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 481, in process_json
    rsp = simplejson.loads(data)
  File "/usr/local/lib/python2.6/dist-packages/simplejson-2.0.9-py2.6-linux-i686.egg/simplejson/__init__.py", line 307, in loads
    return _default_decoder.decode(s)
  File "/usr/local/lib/python2.6/dist-packages/simplejson-2.0.9-py2.6-linux-i686.egg/simplejson/decoder.py", line 335, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/local/lib/python2.6/dist-packages/simplejson-2.0.9-py2.6-linux-i686.egg/simplejson/decoder.py", line 353, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

这种错误信息弄得我一头雾水，在Google上找了半天，也没有什么好的办法。在ReviewBoard的issue archive里有人遇到了和我一样的问题，而ReviewBoard的维护人员建议：修改/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review中的代码(在/usr/local/lib/python2.6/dist-packages下你可能会发现RBTools-0.2beta1-py2.6.egg是个文件而不是目录，不要紧，.egg文件就是一个zip文件，可将其用unzip命令解压后再放到一个名为RBTools-0.2beta1-py2.6.egg的目录中即可，解压后原始RBTools-0.2beta1-py2.6.egg做好更名和备份)，在process_json method开始处加上一行代码：debug(data)。然后在执行post-review时加上--debug选项，观察http post的response数据。

按照网上的建议做了修改：执行sudo post-review --debug，果然有效果，能看到http post后返回的应答内容，居然是公司代理服务器websense的拦截应答。

哇，原来如此，我的.bashrc配置了http_proxy，似乎post-review是向代理发出的http post请求，结果被代理拦截掉了。注释掉.bashrc中的http_proxy变量后，再重复执行post-review命令，这下一切ok了，一个New Review Request成功生成。

第二种模式post-committed review同样是通过post-review工具完成的。命令格式：post-review --revision-range=STARTREV[:STOPREV]。脚本会自动diff两个revision之间的差别并形成review request提交到reviewboard server的。

关于post-review的更多用法，这里不细说了，可阅读官方的Manual。ReviewBoard功能还是很强大的，Review时你可以针对每行代码写Comments，这种Review Code的方式给你足够时间去思考，只要你认真对待，就不会出现盲区、死角，所以新提交的代码就都能被Review到。

使用何种工具做Feature或Defect或Task的跟踪一直是挺让我闹心的一件事。用Excel记录，但却不便于共享、统计和直观展示；Jira算是做的好的工具之一了，但无奈它是商业软件，咱没付那份儿钱，所以也就"无福享用"；Mingle是著名的Thoughtworks公司的产品，虽说不到5个license是可以免费使用的，但它却是出了名的"内存杀手"，无奈我的机器配置太差，运行起来实在太慢，遂没有坚持下去(我"眼冒金星"的渴望着更换一台无所不能的超级计算机^_^)；甚至我曾经用过ONENOTE来做跟踪，可是条目多了后，就基本不可用了。寻觅依旧进行中，这不Trac这款软件进入了我的视线中。

网络让我知道了"Trac"。"Trac"这个名字，估计与Track"异曲同工"。至于Trac具体能做什么，你可以到其Demo站点去体验一下。简单的说，Trac = wiki + 问题处理工作流；Wiki可以用来做知识积累和管理；问题处理工作流恰是我需要的功能。但到底Trac做到啥子程度，那还需要用起来后才能知道。还有一件让我觉得很"幸福"的事，那就是Trac自带一个独立的web server程序Tracd，并且Trac可使用Python 2.5.x自带的SQLite，这样我可以不用安装和配置庞大的Apache和MySQL了。让用户能快速上手应该是Trac值得其他开源软件学习和参考的一个亮点，要知道一些庞大的开源软件繁复的安装和配置过程让很多使用者产生了"挫败感"而"另辟蹊径"了。

Trac是用Python开发的，可以跨平台使用。这里我以Windows上的Trac为例。Trac官方站上有详尽的文档可以指导你的安装、配置和使用。这里用中文做简单介绍吧，留下一个记录，也便于自己以后参考。安装不是最重要的，但是没有了安装却是万万不能的。

1、安装Python, 设置环境变量
对于Trac而言，其解释执行环境Python是必不可少的，虽然Python发布了最新版是3.0.x，但是在已存的Python代码中，Python 2.x版本还是占据绝大多数，过渡到Python 3.0还需要时间。我这里用的是Python 2.5版本。安装完Python后，别忘了将{Python_INSTALL_DIR}和{Python_INSTALL_DIR}/Scripts加入到你系统的环境变量(path变量)中去(一般Python_INSTALL_DIR为"C:\Python25")。

2、使用Windows installers安装Trac
比起手动安装(Manual Install)，在Windows上使用Installer安装Trac更为简便。依次下载和安装：SetupTools、Genshi和Trac 0.11。注意要下载对应Python 2.5版本的安装文件。如果你要用Trac与Subversion接口的话，建议你下载一份svn-python程序，使用其他svn客户端程序似乎不好用。另外Trac只支持连接本地svn repository，不支持远程svn repository。以上安装程序会把相应可执行程序或脚本放到Python相关目录下，所以不需重新设置环境变量。

3、初始化一个工程
完成以上两步，你就可以使用Trac了。Trac运行和管理的基本环境单位是一个工程(Project)。首先你要确定你的工程所在的目录，这里以D:\TracProjects\Foo为例，我们建立一个名为"Foo"的Trac工程。打开一个命令行窗口，执行：
trac-admin.exe D:\TracProjects\Foo initenv
这是个交互执行的过程，你需要填写一些工程的基本信息，比如工程名字、数据库连接字符串等，你大可一路默认下来就可以得到一个默认的工程环境。

4、启动Trac
一切就绪。我们现在就可以启动Trac了。到目前为止，一切都是那么简单，这也充分证明Trac入门简单。在命令行下执行如下命令启动Trac Web server：
tracd.exe -p 8000 D:\TracProjects\Foo
现在你打开浏览器，访问Url: http://localhost:8000，Trac的界面就会展现在你面前。界面上你只能看到"Available Projects"的列表，由于我们只是建立了一个Project，所以你只能看到Foo这一个超链接。点击Foo，进入Foo的工程页面。

5、为Trac Project添加用户
Ticket是Trac Project管理和操作的基本元素，但是在通过上面方式以匿名登录方式打开的页面上你只能"View Tickets"，而无法"New Ticket"；要想拥有"New ticket"的权限，你需要以一个Trac用户的身份登录。初始情况下，Trac没有建立任何用户。Trac创建用户是通过建立"Password file"的方式来完成的。Trac默认的密码文件格式与Apache的相同，都是.htdigest格式的。如果你的系统内没有安装Apache，你可以用Trac wiki上提供的trac-digest.py脚本来生成密码文件。你可以将trac-digest.py文件放到{Python_INSTALL_DIR}/Scripts下面。

# trac-digest.py
from optparse import OptionParser
# The md5 module is deprecated in Python 2.5
try:
    from hashlib import md5
except ImportError:
    from md5 import md5
realm = 'trac'

# build the options
usage = "usage: %prog [options]"
parser = OptionParser(usage=usage)
parser.add_option("-u", "--username",action="store", dest="username", type = "string",
                  help="the username for whom to generate a password")
parser.add_option("-p", "--password",action="store", dest="password", type = "string",
                  help="the password to use")
parser.add_option("-r", "--realm",action="store", dest="realm", type = "string",
                  help="the realm in which to create the digest")
(options, args) = parser.parse_args()

# check options
if (options.username is None) or (options.password is None):
   parser.error("You must supply both the username and password")
if (options.realm is not None):
   realm = options.realm
  
# Generate the string to enter into the htdigest file
kd = lambda x: md5(':'.join(x)).hexdigest()
print ':'.join((options.username, realm, kd([options.username, realm, options.password])))

我们使用如下命令生成密码文件：
python trac-digest.py -u "foo" -p "foo123" >> d:\tracprojects\foo\conf\users.htdigest，
这里我们建立一个用户：用户名为foo，密码为foo123。

我们再次来启动Trac，这次由于带有了用户鉴权，启动命令行与前面略有不同。
tracd --port 8000 --auth=Foo,d:\tracprojects\foo\conf\users.htdigest,trac d:\trarojects\foo
启动后，我们点击login，Trac会提示我们输入用户名和密码，输入foo/foo123后，你就可以看到界面显示：logged in as foo，并且"New Ticket"菜单出现在页面上方。

6、Trac.ini
conf目录下的Trac.ini是针对Foo这个Trac Project的主配置文件。里面各个字段的含义说明在Trac官网都有说明。通过修改Trac.ini你可以很简单的在页面上添加你喜欢的Project Logo。

7、Ticket
Ticket是Trac的核心，默认情况下，Trac为Ticket设定了诸多属性，并且设定了围绕Ticket的默认工作流。对于Ticket的每个属性字段，我们都可以通过trad-admin工具对字段取值进行增删改，以适合你的需要。诸如：trac-admin d:\TracProjects\foo  component add Webms foo，这句的含义就是添加一个属于foo工程的名为"Webms"的组件值。Ticket没有类似"Deadline"的时间属性，我们可以用milestone和priority来约束解决Ticket的时间范围。在"View tickets"页面中，Trac内置了多种"Report"，你同样也可以自定义搜索，但是目前用户尚不能在"View Tickets"中保存自定义搜索为固定的"Report"，但是你可以将自定义搜索语句放到一个WIKI页面的链接选项中，这样你就可以方便的直接得到搜索结果了，无需每次都配置搜索条件。

8、WIKI
Trac内置WIKI引擎，你可以通过trac-admin d:\TracProjects\foo wiki list来查看当前Project的所有WIKI page名称。你也可以通过trac-admin d:\TracProjects\foo wiki import WIKI_PAGE_NAME new_WIKI_page.txt为Foo Project导入一个名为"WIKI_PAGE_NAME"新WIKI页，该页内容来自文件new_WIKI_page.txt。和所有其他Wiki一样，你可以任意定制你的Project中的任意Wiki页面。

从上面的8个步骤来看，Trac简单而且实用，我已经根据我自己的需要对Trac Project进行了初步定制，并导入了我要追踪的需求、任务和问题，更多的高级功能还需要一段时间去发掘，今天的发掘到此为止了。

近日，Bash Shell正式发布了其4.0版本，该版本可以看作3.x的bugfix版，同时增加了诸如"Associative Arrays"等新特性。在Bash Shell的官方站点你可以下载到最新的4.0版本，不过在GNU的Bash主页上，似乎还找不到4.0版本的所在。Bash作为Linux系统默认Shell，一直受到广泛关注，而且它还是目前几大Shell(Bourne Shell, C Shell、Korn Shell、Bash Shell)里唯一还继续维护和更新的Shell版本了，目前其主要维护者是Chet Ramey，Bash的两个原始作者之一。

部门内部一直使用C Shell作为Unix账户的默认Shell，估摸着一切源于“继承性”。以前对Shell的关注不多，认为只是工具，用什么Shell都无所谓；近来一直在关注工具使用的高效性，Bash Shell也就再次进入我的视野，花了三天时间将《学习Bash》这本书通读了一遍，收获颇丰，纠正了我以前很多对Shell错误的理解，也加深了我对Shell的认识。《学习Bash》这本书市面上已经绝版了，各大网购站点都亮出“缺货”字样。其英文原版是Oreilly的“Learning the bash shell 2nd edition”，而目前最新版本则是“Learning the bash shell 3rd edition”，内容变化不大，没有中文译版，可以到网上下载电子版阅读。

Bash在命令行编辑下支持的Emacs和Vi模式让我使用起来很得心应手，这样即使在命令行下我也可以使用VI的快捷键对命令行进行编辑，手指可以完全不用离开键盘的常用操作区。这也直接促使我将Bash“扶正”。昨天已经让管理员把我的Unix帐户从C Shell正式换成了Bash Shell。

现在也逐渐认识到：深入理解Shell脚本更有助于你深入理解Unix的文化，对在Unix上写程序也大有裨益。

拥有了某种工具，往往不等于就能使用好这种工具。拥有工具简单，用好工具、发挥出最大作用则较难。CSCOPE让VIM的使用者有了与SourceInsight"平起平坐“的机会，但是能否将CSCOPE的功能发挥出来还要看你是如何使用它了。

自从VIM”重装上阵“以后，我一直在使用CSCOPE。在使用过程中还是发现了一些”别扭“的事情。一般我会在一个大型Project的源代码的顶层目录使用CSCOPE -Rbq来生成cscope.out文件，如果你在cscope.out所在目录执行VIM的话，VIM会优先将cscope.out作为”符号交叉索引库“(与ctags相比)，但是如果你在某个子目录下执行VIM进入编辑状态的话，因当前目录没有cscope.out，所以VIM无法加载cscope.out文件，也就无法在文件间跳转。而必要时你还需要手动执行命令行:cs add {TOP_LEVEL_PATH}/cscope.out才能连接到cscope，发挥其功用。

还有一种情况，如果你有两份基本相同的代码库，其中一份A建立了cscope.out文件(在A的顶层目录使用CSCOPE -Rbq)，而另一份B没有建立，当使用B查看代码或编写代码时，手动add A库的cscope.out文件，然后打开B库子目录的一个文件，找到一个符号，用ctrl+]进行跳转，VIM会列出符号列表，当你选择一个时，VIM却提示你“E429: File xx/yy.h does not exist”，原因很简单，就是Cscope以相对路径存储了符号的位置，你从B库的工作目录下当然跳不过去了。

现在我们就要解决这两个问题，我们要做到：
1) 无论在任何目录下执行VIM，VIM都会自动加载当前阶段常用的cscope.out，而无需手动加载；
2) 让cscope.out内的符号以绝对路径的形式存储，这样无论在何处进入VIM，都能跳转到相应的符号定义的文件中；

其实解决上述两个问题的方法有多种，这里只是先说说我的一种方法，估摸着还不是最优的。在cscope官方有篇文章“Using Cscope on large projects”，里面关于cscope.out生成的方法可以解决第二个问题，即使用cscope.files来生成cscope.out。cscope.files中的内容很简单，就是文件列表，将你要进行扫描的所有文件的路径cscope.files中，然后执行cscope -bqk即可得到cscope.out。如果你要解决问题2，那你就将要进行扫描的文件的绝对路径名加入到csccope.files中。用find命令可以轻松帮你做到这一点。这里将这个工作放到了一个shell脚本中去完成了，脚本具有一定的通用性(我的脚本水平：菜鸟级^_^)：
/* gen_cscope_files.sh */
#! /bin/bash

TARGET='/export/home1/username/cscope_db/cscope.files'
gen_cscope_files_usage() {
        echo "gen_cscope_files.sh 源码顶层目录(绝对路径) 待扫描子目录1 [待扫描子目录2] ... [待扫描子目录N]"
}

if [ -z ${1} ]; then
        echo "请输入起始目录!"
        gen_cscope_files_usage
        exit 1
fi

if [ ${1:0:1} != '/' ]; then
        echo "请输入起始目录的绝对路径形式!"
        gen_cscope_files_usage
        exit 1
fi

if [ ${#} -lt 2 ]; then
        echo "请输入你要扫描的子目录列表!"
        gen_cscope_files_usage
        exit 1
fi

if [ -s ${TARGET} ]; then
        cat /dev/null > ${TARGET}
fi

for dir in $@
do
        if [ ${dir} != ${1} ]; then
                find ${1}/${dir} \
                -name "*.[hc]" \
                -print >> ${TARGET}
        fi
done
这样你只要选择好你的cscope.files的存放位置(在上面的脚本中是写死的，当然你也可以修改脚本，通过命令行参数传入cscope.files的存放位置)，给gen_cscope_files.sh一个源码的顶层目录(绝对路径)，再给出你要扫描的子目录列表即可，比如：gen_cscope_files.sh /export/home/username/proj/foo  include src

以上解决了问题2，那问题1呢？我们在.vimrc中做文章。以下代码保证了每次vim被执行后都会将上面生成的cscope.out加载。
if has("cscope")
        if filereadable("/export/home1/username/cscope_db/cscope.out")
                cscope add  /export/home1/username/cscope_db/cscope.out
        endif
endif

到目前为止，你在B库中在任意目录下打开的文件都可以找到相应符号的位置。

国内很多学习Python的人都喜欢看"A Byte of Python"，这是一本由印度小伙儿Swaroop C H写的书，之所以受到大家关注和欢迎，想必其简单而实用的写作风格是其中的重要原因吧，作为入门书很适合。我的Laptop中就有一本中文翻译版，不过书中用的还是Python 2.3.4版本。本月3日(2008-12-3)Python 3.0 Release版祭出，Swaroop C H也在其站点上增加了A Byte of Python for 3.0版。在下载新版"A Byte of Python"的同时，我又发现了Swaroop C H的另外一部作品"A Byte of VIM"。

刚工作的时候，一直用原始的VI(非VIM)在Unix上写代码，之所以选择原始的VI是因为部门里的老同事都使用它，VIM用的人不多，刚出校门的我还十分不适应VI的操作(在VIsual Studio上用IDE惯了)，形成VI习惯还是很痛苦的，学习过程似乎没有什么成就感。看着其他一起入司的同事使用VIM的各种"奇技淫巧"分割窗口、折叠代码、自动补齐、通过快捷键在代码文件间跳来跳去，我却仍没有一些想深入学习的感觉(也许当时将精力都投到Java上了吧^_^)。

今年一直在努力通过各种方法(双显示器、分布式编译等)提高自己的工作效率，提升工作效率是大势所趋，随着工作责任的增多，工作任务相应的也要多起来，时间还是那些，这就需要你在短时间内高效的完成工作。我们能做的除了做好时间管理、理顺工作流程外，对于个体来说采用更高效的工具以及熟练掌握这些工具就是高效工作的一个突破口了。眼下对于我来说重要的就是让VIM"重装上阵"(工作多年了，还是用使用VI的方法去使用VIM这个强大的工具，有些说不过去了^_^)。

与VI相比，VIM显然更强大，让人惊异于网上的各种VIM的插件和辅助软件，将这些结合在一起后，似乎一个无所不能的IDE就这样诞生了，也许这就是Unix文化的魅力所在吧。Swaroop C H的"A Byte of VIM"，特别是其中的"VIM, Programmer's Editor"一节中将一个程序员应该常用到的插件和辅助软件都集中在了一起，从头到尾读一遍，你就会能体会到VIM的强大。关于如何使用VIM高效编辑的最好的Guide类文档当属Vim的Founder Bram Moolenaar所写的"Seven habits of effective text editing"了，目前该文档已经进化到2.0了。Bram在文中的一句话我觉得对学习Vim则是很有指导意义："Learning every feature of Vim might make you the great award of Vim, but it will not be very effective. And it will be impossible to make everything a habit." 在VIM纷繁芜杂的功能中找到符合自己的实用功能并形成编辑习惯才是最高效的。

部门服务器上的VIM依旧停留在6.3版本，很多我需要的VIM新功能都不支持。为了不影响大家使用，我还是决定在自己的用户目录下重新编译一个VIM，最新版7.2，这样自己可以按照自己的需求定制。在SunFreeWare网站下载Vim7.2 For SPRAC Solaris 9的源码包，解压后发现VIM的目录组织很清晰整洁，Configure & Make，编译过程很顺利也，甚至连一个Warning都没有，10分钟编译完毕。Make install到自己指定的目录(需要在Configure的时候使用--prefix参数)，修改path。再一执行Vim，版本已经变成了7.2了。

Ctags一直在使用，不过发现系统里的Ctags版本较低，为了能更好的配合Vim 7.2，我还是下载了一个Ctags 5.7版本源码，重新编译了一个自己用的CTags。在测试项目顶层Ctags -R生成tags文件，测试了一把，一切OK。

Taglist以前一直没有用过，下载其最新版taglist_45.zip，在本地$VIM_INSTALL_HOME/share/vim/vim72解压，
  inflating: plugin/taglist.vim      
  inflating: doc/taglist.txt
在测试项目里打开一个源文件，命令栏下输入: TlistToggle，Vim打开一个新的窗口，显示你当前Vim Buffer里的宏、Typedef、Functions、Variables等。你可以使用"Ctrl+w, Ctrl+w"在两个窗口间切换，对于函数较多较长、size较大的源文件的编辑有很大效率提升，list窗口中的内容也是普通文本，可以用各种搜索功能定位函数或变量，然后回车跳转到主窗口的相应源码。

Ctags和Taglist都功能有限，CScope才是集大成于一身，Vim内置了8种CScope的查询操作，比如你可以查询到当前光标下的函数被哪些方法调用，这个功能相当实用。由于我们服务器上没有CScope，我下载了源码编译，结果很不顺利，总是报错，无法解决，无奈只能让管理员在主机上用已经做好的安装包安装一个了。然后下载
cscope_maps.vim，将之放入.vim/plugin下面，cscope_maps.vim将冗长的cscope命令映射为热键了，便于使用。安装好后打开Vim，使用热键，vim在状态栏中居然提示不支持cs命令。Help了一下CScope，发现Vim默认编译时是不支持CScope的，需要重新Configure，重新Make，这次configure就要加上--enable-cscope选项了。另外CScope单独执行时会用你默认的编辑器打开相应文件，你可以通过在shell里设置‘EDITOR’环境变量来指定编辑器。

有了CTags、Taglist和CScope，你的Vim将呈现出丰富多彩的界面。窗口多了，别晕了。

Vim新版支持了内置的补全功能，通过Ctrl+N or Ctrl+P可在补全列表中前后选择；内置的补全功能会在当前缓冲区、其它缓冲区，以及当前文件所包含的头文件中查找以光标前关键字开始的单词，也是平时用的最多的补全功能。

Snippets，看到这个单词也许使用TextMate的人最为熟悉不过了，通过敲击几个关键字符+TAB间即可帮助你展开一些最常用的代码，减少输入的重复工作，比如for, while, if以及C++等面向对象语言中的class结构，你只需要输入内容即可。Snippets同样是通过插件snippetsEmu的形式提供到Vim中的。只需要Vim网站下载两个文：snippy_bundles.vba和snippy_plugin.vba，千万不要别扩展名给蒙住了，这两个文件不是Windows上的那个VBA脚本文件，而估计是vimball文件，下载后分别用vim打开，然后执行"source %"即可。VIM会在.vim/下的after和plugin下放入若干文件，用以支持Snippets功能。你可以打开~/.vim/after/ftplugin/c_snippets.vim，看看它对C语言都有哪些Snippets，如果觉得不符合你的习惯可以修改之。随意打开一个C源文件，输入do+TAB，可以看到：
do
{
       
} while (<{}>);<{}>
光标停留在中央，待你输入内容；输入后，点击Tab，光标会跳到下一个<{}>中，待输入完内容，再TAB，则最后一个<{}>消失，输入完毕。是不是也很强大:)

Vim的Quickfix模式是我以前没用到的，Quickfix这个就好比Visual Studio的“输出窗口”，build过程出现的错误都会在里面列表显示，你在这个窗口里将光标切换，主窗口就会显示对应的错误位置。前提你要在Vim内执行Make，一般我会使用:cw打开quickfix窗口，用cn和cp在quickfix中的错误行中切换。

其实以上每一个新功能都很复杂，形成习惯需要一个过程，但是一旦形成了习惯，你的效率将会有大幅提高。

今天是冬至，也是入冬以来感觉最冷的一天，毫不夸张的说：你一张嘴，牙就冻上了。上午LP在家收拾卫生，我继续用Scons改造现有的项目。下午出去理发，头发长长了后，似乎会造成思维迟钝^_^。

试验性的用Scons改造现有的project，过程中对Scons了解又多了一些。上篇文章对Scons的性能没有给出定论，经过对Scons的深入后，发现Scons在执行初始时的性能的确不够快，这是因为Scons启动后，会对全部SConstruct以及下面子目录中的SConscript进行分析，子目录越多Sconscript文件个数越多，性能也就越差。但是这种分析也有一个优点，就是能帮你提前发现你SConscript中的一些“语义”错误，比如如果你在编译两个基础库，一个叫add，一个叫sub，这个基础库源码分别分布在两个目录add和sub中，编译后将分别生成libadd.a和libsub.a的库文件，但是如果你马虎了，在编写SConscript时将target都写成了'add'或都写成了'sub'，则Scons会在执行gcc之前就帮你找出这个"语义"错误，提示如下：
/export/home1/tony_bai/xxlib>scons -f SC*t
scons: Reading SConscript files ...
scons: *** Multiple ways to build the same target were specified for: /export/home1/tony_bai/xxlib/lib/libsub.a  (from ['/export/home1/tony_bai/xxlib/add/libsub.a'] and from ['libsub.a'])
File "/export/home1/tony_bai/xxlib/sub/SConscript", line 3, in <module>

Scons脚本基本写的差不多了，编译也ok了，但是编译出来的可执行程序在执行时却出现了问题：提示找不到某.so文件。而用项目"原配"的Makefile编译出来的可执行程序却执行的很好，没有类似问题，百思不得其解。将.so文件所在目录放到"LD_LIBRARY_PATH"中，问题得以解决，但这更加深了对这一现象的质疑。起初我一直以为是Scons在编译选项上不规范造成的，而Scons使用gcc -G -o xx.so xx.o来编译也的确有值得的怀疑点，-G选项是我从未见过的gcc编译选项，查了半天手册也没有对该参数的说明，遂放弃。上工具吧！先用ldd对编译出来的可执行文件进行分析，我们先来假设用Scons编译出来的可执行程序名字为Bin-scons，用"原配"Make编译出来的可执行程序名字为Bin-make。ldd将列出可执行文件中动态依赖的库的名字，并在本机定位出各个动态库的位置。对Bin-scons和Bin-make分别ldd的结果却让我大吃一惊，Bin-scons的ldd结果很正常，xx.so出现在list中，并且其位置为我刚刚加入到LD_LIBRARY_PATH中的那个目录；但是Bin-make的ldd结果中却不见了xx.so的踪影，这是怎么回事呢？回头翻看Makefile，并且又执行了多遍Make，项目的Makefile明明是构造了xx.so，在生成Bin-make时链接了xx.so，并且Bin-make中使用了xx.so中提供的接口。再次仔细对比Make和Scons编译.so时的差别，这回发现了些许不同的地方，"原配"的make在编译.so时，除了用了-shared -fPIC之外，还用了"-c"选项，而从Scons日志中只能看到gcc -G -o libxx.so xx.pic.o，显然Scons先控制gcc将xx.c编译为xx.pic.o，再由xx.pic.o构成libxx.so，而且我发现用Scons和Make编译出的.so文件大小居然不同。显然"-c"对两个编译过程带来了影响。一般来说，我们在编译一个动态库时是不会使用"-c"的，这里先不论项目Makefile写的是否ok，单说"-c"会给编译过程带来什么吧。打开gcc的"--verbose"开关，我们来试试使用和不使用"-c"gcc都做了些什么。还是以add.c为例，将add.c编译为libadd.so。

gcc -o libadd.so -shared -fPIC -c add.c --verbose
执行结果：
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc add.c -quiet -dumpbase add.c -version -fPIC -o /var/tmp//cca0mHxn.s
GNU CPP version 3.2 (cpplib) (sparc ELF)
GNU C version 3.2 (sparc-sun-solaris2.9)
        compiled by GNU C version 3.2.
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/include
End of search list.
 /usr/ccs/bin/as -V -Qy -s -K PIC -o libadd.so /var/tmp//cca0mHxn.s
/usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 Solaris_9_CBE 2001/04/02

gcc -o libadd.so -shared -fPIC add.c --verbose
执行结果：
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc add.c -quiet -dumpbase add.c -version -fPIC -o /var/tmp//ccz128Nl.s
GNU CPP version 3.2 (cpplib) (sparc ELF)
GNU C version 3.2 (sparc-sun-solaris2.9)
        compiled by GNU C version 3.2.
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/include
End of search list.

 /usr/ccs/bin/as -V -Qy -s -K PIC -o /var/tmp//ccoU5RTD.o /var/tmp//ccz128Nl.s
/usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 Solaris_9_CBE 2001/04/02
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy -o libadd.so /usr/local/lib/gcc-lib/sparc-sun-
solaris2.9/3.2/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtbegin.o -L/usr/local/lib/gcc-lib/sparc-sun-
solaris2.9/3.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/../../.. /var/tmp//ccoU5RTD.o -lgcc_s -lgcc_s
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtend.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.276

对比这两次的执行结果，我们可以发现，使用了-c的编译过程实际上不是一个完整的共享库(动态库.so)的构建过程，而只是一个带有"-shared, -fPIC"的目标文件(.o)的编译过程，缺少gcc crt目标文件的链接过程，只是目标文件被命名为libadd.so了。这恰恰能解释我们前面提到了两点疑问了。为什么ldd Bin-make时没有发现其依赖xx.so以及Bin-make执行时一切ok，没有报“找不到xx.so”，这一切都是因为xx.so实际上是以.o形式存在的一个文件，在构建Bin-make链接xx.so时，实际上做到是静态链接而不是动态链接，xx.so中的接口代码都已经存在于Bin-make中了，所以ldd无法找到对xx.so的依赖，Bin-make执行时也无需找到xx.so了。看来这是项目Makefile中的一个问题了，只是这个"问题"隐藏太久而未能被发现罢了。

从收音机中得知"冬至"这天应该吃饺子，晚上和LP煮了两包水饺，热腾腾的，吃得直打饱嗝^_^。