修改exvim目录过滤逻辑为匹配拒绝

exVim 是一个非常优秀的 Vim 环境,通过它能够省去很多 Vim 插件的配置工作。自从使用上 exVim 后,我基本没有再自定义 Vim 插件,完全依赖 exVim 打包的辅助功能。

最近让我略有不爽的使用问题是:exVim 默认的 file filter 和 dir filter 都是匹配通过的,即“匹配 filter 过滤条件的目录和文件被通过,列入项目目录、文件列表中”。

exVim 的 dir filter

对于文件来说,设置匹配通过毫无问题。因为我也想要项目中仅包含 “.cpp,.c,.h,.py” 这样的源代码文件,选出来匹配这些模式的文件就是我希望的结果。

但是对于目录来说,设置匹配通过就与我通常的需求相悖了。一般情况下,项目目录下的所有目录都是程序需要的。但是一些专门存放测试程序、测试框架、输出文件的目录,我其实不希望显示在我的项目中。而且 exVim 中的目录过滤貌似仅限在项目顶层目录中,过滤的意义不大。

所以我修改了一下 exVim 的代码,将默认的 dir filter 含义修改为匹配拒绝,即:“匹配 dir filter 的目录被拒绝(被过滤掉),无论它在哪一级。"例如,我将 dir filter 设置为 “test,output”,那么我项目目录下所有叫做 test 或者 output 的子目录都不会显示到项目目录列表中,而不妨碍其它名称目录的通过。

可以想见两个 filter 采用不同的通过逻辑并不是 exVim 开发者希望看到的,所以我想这个修改也没必要提交给开发者。不过我仍然觉得这是很有用的一个修改,所以拿出来分享一下。修改的补丁文件见:http://share.solrex.org/ibuild/exvim-dir_filter-8.05_b2.patch

PS: patch 文件中还有一个改动是将 quick_gen_project_PROJECT_autogen.sh 文件从项目目录下,移动到项目目录下的 .vimfiles.PROJECT/ 目录中,原因是看起来碍眼 :)

代码行统计工具-CLOC

在工作中有时会有需要统计代码的行数,一般会用 wc 给出一个大致的结果。只不过在源代码文件分布比较分散,且存在多种不同类型语言的源代码时,wc 就不是特别适合了。

在公司内部也见过一些同事实现类似功能的脚本,但我想这应该是一个通用的需求,于是就找到了这个工具 - CLOC。其实就是一个 perl 脚本,很好用,统计报告也很清晰。在这里推荐一下。下面是一个统计 leveldb 源代码行数的例子。

$ cloc .
     128 text files.
     123 unique files.                                          
     353 files ignored.

http://cloc.sourceforge.net v 1.55  T=0.5 s (238.0 files/s, 46718.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C++                             60           2012           1258          13124
C/C++ Header                    52            968           1458           2690
HTML                             3             84              0           1094
C                                1             33              7            255
make                             1             43             17            153
CSS                              1             10              1             78
Bourne Shell                     1              9             19             46
-------------------------------------------------------------------------------
SUM:                           119           3159           2760          17440
-------------------------------------------------------------------------------

在 Ubuntu 9.04 上安装 Kscope

Kscope 是我很喜欢的 Linux 平台上的代码查看工具,因为我不会用 Emacs,vim + ctags 又用得不熟,看看小程序还可以,看大项目就傻眼了。以前也尝试过 Source-Navigator(这个项目N年没更新,06年时候我装都装不上,08年底居然又复活了,有空了再去试试)、Eclipse、Kdevelop、CodeBlocks,总之都没有 Kscope 用着最舒服。Kscope 让我欣赏的特点主要有:

1. 它号称是代码编辑环境(source-editing environment),而不是IDE。我不用在建立 Kscope 项目时烦心地去选择项目类型、编译器、编译选项等等。编译我有 Makefile,我就是找个工具看看代码,用得着那么麻烦吗。 建立 Kscope 项目时只需要干两件事:选择项目名、项目保存地址和添加源文件。

2. 它不会在源文件目录下建立一堆乱七八糟的文件,影响市容。我记得 Eclipse、CodeBlocks 等都会把项目信息保存在源文件目录下,而 Kscope 的项目保存位置可以自己选,比如我一般都保存在 workspace/kscope 目录下面,这样对要查看的源文件目录没有任何影响。因此 Kscope 的项目和源文件基本没关系,我可以添加任何位置的源文件到某个项目中去。

3. 它不会去读非指定类型的文件。这是针对 Eclipse 来说的,每次在 Eclipse 项目中搜索时,一堆 .svn 目录中文件的结果让我感觉非常闹心,两年没用不知道现在的 Eclipse 是不是更智能点儿了,但是 Eclipse 改不了的毛病就是慢和吃内存。

4. 它支持代码查看的基本功能。其实我最常用的也就那么几个功能:语法高亮、同时打开多文件、整个项目中搜索字符串、查找函数定义位置和引用、项目文件列表+搜索。在这些条上据说 Windows 下的 SourceInsight 做得更好,但我没用过没有发言权。

简而言之,Kscope 与其它工具比就是快、简单、省心。但是时代在变革呀,转眼到了 KDE4 的时代,而 Kscope 仍然停留在 KDE3.5 上。现在的 Ubuntu 9.04 的依赖关系里,居然已经撤掉了 Kscope,在 9.04 上 sudo apt-get install kscope,会得到这样的消息:E: Couldn't find package kscope,真是让人丧气。

其实 Kscope 之所以不能安装,主要原因是它依赖于 Kate 的两个库:libkateinterfaces.so.0 和 libkateinterfaces.so.0,只需要从 KDE3.5 的 Kate 中提取出来这两个库安装到系统中后,Kscope 就可以正常运行了。Ubuntu 9.04 的依赖关系中虽然找不到 Kscope,但是 Ubuntu 的软件仓库中还有 Kscope 的包,我们可以手动下载安装。下面这个脚本的功能就是自动安装 kscope 到 Ubuntu 9.04,稍微修改一下也可以用于在其它 KDE4 桌面系统中安装 Kscope,或者解决 Kscope 无法运行的问题。您也可以从这里下载到该脚本:

#!/bin/bash
# This script helps you install Kscope on Ubuntu 9.04.
# You can also use it to fix "Kscope doesn't run in KDE4" bug.

echo "Determining machine hardware name... "
MACHINE=`uname -m`
case "$MACHINE" in
  i386 | i586 | i686)
    ARCH="i386"
    ;;
  x86_64)
    ARCH="amd64"
    ;;
  *)
    ARCH="i386"
    ;;
esac

# If Kscope is not installed, install it.
which kscope &> /dev/null
if [ $? -ne 0 ]; then
  echo "Installing kscope..."
  sudo apt-get install kscope || \
  wget http://archive.ubuntu.com/ubuntu/pool/universe/k/kscope/kscope_1.6.0-1_${ARCH}.deb && \
  sudo dpkg -i kscope_*.deb || \
  sudo apt-get -fy install || \
  echo "Oops, some error happens..."
fi

kscope -v &> /dev/null
if [ $? -eq 0 ]; then
  echo "Kscope works fine."
  exit
fi

echo "Downloading KDE3 libraries needed by kscope..."
wget http://ftp.debian.org/debian/pool/main/k/kdebase/kate_3.5.9.dfsg.1-6_${ARCH}.deb
dpkg -x kate_3*.deb kate

echo "Installing KDE3 libraries..."
sudo cp kate/usr/lib/libkateinterfaces.so.0.0.0 /usr/local/lib/
sudo cp kate/usr/lib/libkateutils.so.0.0.0 /usr/local/lib
sudo ln -s /usr/local/lib/libkateinterfaces.so.0.0.0 /usr/local/lib/libkateinterfaces.so.0
sudo ln -s /usr/local/lib/libkateutils.so.0.0.0 /usr/local/lib/libkateutils.so.0
sudo ldconfig

echo "Finished."

应用程序打包技术之一(源代码篇)

1. 应用程序打包技术之一(源代码篇)
2. 应用程序打包技术之二(deb篇)
3. 应用程序打包技术之三(rpm 篇)
4. 应用程序打包技术之四(exe篇)

相信很多朋友都曾经为方便做某件事写过自己的小程序(像我写过的 casnetsendsms),但很多怕都是藏在深山没人识,最后不了了之,自己也把它们丢在角落里忘记了。

把这些小工具上传到技术论坛或者 CSDN 下载频道之类的网站,还是能收到一些关注的,而且还能攒积分和声望。但是为什么不把它们发布出去呢?估计有几个原因:源代码太乱,编译又挺复杂,不好意思给别人看;二进制程序包不会打,不知道该怎么发布。

因此我打算在本系列文章中分享一下我的程序打包经验,目前来讲计划有四篇:源代码篇、deb 篇、rpm 篇和 exe 篇。这些技术在网上您都能找到,因为我也是从网上学习的,算是一个笔记和汇总吧。如果您有好的批评或建议,不妨在评论中指出,帮助我完善这篇文章。

源代码篇

发行源代码包是件最简单的事情,因此也在最先介绍。有同学会说,打个压缩包不就完了嘛。的确如此,但是在压缩之前您也要有几个注意事项:

1. 删除版本管理目录,比如 .svn,.cvs 之类的目录。像 Subversion 版本管理软件,会在每个目录下都建立名为 .svn 的目录,里面一般保存着目录下文件的最新版本,可以用来 revert 修改。不删除 .svn 目录,会使源代码包臃肿,而且最重要的是可能会有安全隐患。.svn 目录下还包含您的用户名和 SVN 服务器信息,可能您并不想让别人知道。但是如果您网速够快的话,可以重新 svn export 一份,而不是仅仅从您的 svn 树上拷贝一份出来,那就没有 .svn 目录了。

2. 规整一下编译过程,如果编译过程不规范,您应该添加一个 README。如果您的代码不是脚本,很可能是需要用户编译的。如果编译过程规范,*nix(Linux/Unix, CygWin, Mingw 等) 下就是 ./configure, make, make install,用户很容易理解。但如果编译过程不规范,您就最好添加一下 README 或者 INSTALL 文件,指导用户该如何编译。使用 MS VisualStudio 的用户要注意工程文件的整洁性,最好导出一个 Makefile(是的,VS 也可以用 Makefile),这样用户就不必打开项目,在 CMD 命令行用 nmake Makefile 就可以编译了。

3. 删除二进制中间文件。在 *nix 开发者中,这一般不难做到,Makefile 中一般都会写一个 clean 目标;但是 MS VS 用户一般不会注意那些编译时生成的 .obj 文件。源代码包就应该是源代码,最多包含可执行程序和文档,而不应该包含其它任何二进制的文件。否则您的源代码包就会很大,而且对用户也是困扰,到底哪些文件有用呢?

4. 修改编译目标从 debug 版本到 release 版本。*nix 下,这一般意味着 CFLAGS 要改成 -O2 而不是 -g;VS 一般意味着将目标从 debug 转为 release。这样用户生成的可执行程序才能足够小和足够快,他们如果有能力自己调试,会知道如何将选项改回去的。

5. 添加知识产权信息,就是授权协议。小程序大家一般都不在乎,但如果是您在这个项目上花了足够的心血,还是最好选择一个自己喜欢的授权协议。可以将协议声明放在每个源文件的最前注释中,也可以在项目的根目录下放一个 license 文件。

6. 不要用 rar 包。在 Windows 下推荐使用 zip 格式压缩;*nix 下推荐使用 .tar.gz 或者 .tar.bz2 格式。因为这些格式在这些系统上不需要安装额外的软件解压。WinRAR 是一个商业软件,而且 RAR 格式也是受版权保护的。

打包命令:

在 Windows 下,如果您使用开源软件 7-zip 来压缩 zip 包,可以使用这个命令(首先将 7-zip 可执行文件目录添加到 PATH 环境变量中):

7z a foo.zip foo

*nix 下,就是下面几个命令了:

tar czvf foo.tar.gz foo
tar cjvf foo.tar.bz2 foo
zip -r foo.zip foo