标题: linux 开发软件列表
作者: dsj
时间: 2008-10-20 22:55
标题: linux 开发软件列表
软件集成开发环境（代码编辑、浏览、编译、调试）
Emacs
Source-Navigator 5.2b2
Anjuta (可用yum安装)
代码索引工具
Cscope
KScope
GLOBAL (可用yum安装)
调试器(GNU gdb的GUI前端)
DDD
Insight 6.4.0
KDbg
评测器(内存、性能、覆盖等的profiler，类似IBM Purify)
Valgrind ，FC5自带3.1.0-2
ggcov(GNU gcov的GUI)
kprof(GNU gprof的GUI)
KCachegrind
BoundsChecking
代码静态检查工具(类似Windows平台的PC-Lint)
Splint (可用yum安装)
flawfinder
代码静态测量工具
--暂缺，Windows上非开源的LineCount()统计C/C++/Java代码还凑合。
PyMetrics()测量Python代码复杂度。
罗列了好些C static metric tools。
软件构建系统(build system)
SCons (用yum安装的版本太低)
CMake
GNU Make
交叉工具链
crosstool
代码版本控制系统及相关工具
Subversion (用yum安装)
WorkBench (pysvn的附带物)
StatSvn
mpy-svn-stats
ViewVC
测试框架
CppUnit
CUnit
http://cunit.sourceforge.net/
代码差异工具（比较/制作和应用补丁）
GNU diffutils
kdiff3 或者（可用yum安装）
代码在线文档
doxygen
离线文档
DocBook
XMLMind
代码格式化
astyle(Artistic Style)
indent
UML建模
ArgoUML
软件工程事务(BUG等)跟踪（类似IBM ClearQuest）
Trac (基于Pythyon，用yum安装)--感觉和BugFree一样小巧
BugFree (基于PHP+MySQL)－－中小规模软件适用
BugZilla －－配置复杂，使用麻烦
自动化持续构建与测试系统（类似IBM BuildForge）
BuildBot (基于Python)
Cabie （基于Perl和MySQL）
系统级别测试框架
DejaGNU （基于Expect，因而基于Tcl）
QMTest （基于Python）
Linux实用工具
yum ,FC4自带yum-2.3.2-7, FC5自带2.6.1-0
wget
cURL
http://curl.haxx.se/
Wireshark(原名Ethereal) ,(FC自带版本较低)
NcFTP
tftp和tftp-server yum -y install tftp-server和tftp
rp-pppoe (FC自带版本较低)
minicom （FC自带）
TightVNC
Wine+IEs4Linux
StarDict
fcitx
KchmViewer
kmhtConvert
永中Office
webmin sourceforge.net,插件结构
Rsync
wxDFast
FlashGot
Amarok (iTunes风格的音乐播放器，可yum安装它以及mp3插件amarok-extras-nonfree。wma没搞定)
xmms (winamp风格的音乐播放器，可yum安装它以及mp3/wma插件)
MPlayer (Linux下最优秀的多媒体播放器之一，播放速度、支持的文件格式都出色，可yum安装。我的可以播放MPEG4文件、row data和.mp3)
VirtualBox
qRFCView
打字练习软件
Tuxtype, for Linux&Windows,
TypeFaster, for Windows,
Python库/工具
pyserial
pysvn
twill
pexpect
wxPython (可用yum安装，名称wxPython和wxPython-devel)
Snack
PIL
ReportLab
SIP (可yum安装，名称Python-SIP)
dogtail
PyChecker
pylint (Logilab.org还提供了基于Python的人工智能、科学计算等包)
Winpdb
pydb
SPE
Python数据库方面有个规格Python Database API 2.0，有遵循此规格的对各现有DBMS（sqlite,mysql等）的包装，如pysqlite,MySQLdb
python SIP/MGCP stacks
Shtoom
Divmod Sine
PJSIP (Pjsip now supports Python abstraction for PJSUA-API...)
Sipx利用Python实现了SIP Forum Basic UA Test Suite()
C/C++库/工具
wxWidgets (可用yum安装其GTK绑定，名称wxGTK和wxGTK-devel)
STL-Boost中文站点
NullHttpd
PCRE (Perl正则式兼容的，Windows版)
GNU Regex (GNU/Linux环境常用的两个正则表示式包就是PCRE和GNU Regex，FC5上都装了)
Libxml2 (The XML C parser and toolkit of Gnome)
Xerces-C++ (A validating XML parser written in a portable subset of C++ by the Apache project.)
expat (XML parser written in C)
ACE (跨平台C++库/框架)
APR (跨平台C库)
NSPR (跨平台C库)
KXML Editor
jedit sourceforge.net,插件结构。用处不大。
jdk1.5 java.sun.com
SIP协议栈相关
OpenSER
SER
sipX
sipsak
SIPp
xvidcore1.1.0 (XViD MPEG4 codec)
live (RTSP_Server)
编译器/识别器生成工具
Bison
ANTLR
ABNF工具
(1)Parser generators：
APG (ABNF Parser Generator)
Yacker
(2)Test case generators:
abnfgen
(3)Verifiers:
There's Bill Fenner's ABNF checker (for cut-and-pasted grammar), an ABNF parser in Perl from Harald Alvestrand, and
Chris Newman's abnf.c, a widely used validator (here's its cut-and-paste frontend).
跨平台的万能编辑器Emacs配合CEDET/ECB/Cscope/GDB-UI这4个插件之后就成了一个完整的IDE。接触Linux几年来总是对它
崇敬畏惧，这两天下决心学习了一下，感觉(1)“学习曲线”并不是以前想象的那么“陡”；(2)编辑功能确实像传说中的那么强。对它稍作定制，就能在写代
码过程中自动应用特定编码风格。集中了许多C/C++风格规定。
我认为Emacs适合于编辑自己的代码(编辑功能很强，分析能力稍差)，而Source-Navigator适合于阅读别人的代码(编辑能力稍差，分析能力很强)。
我试用了eclipse用来开发C/C++的cdt插件，对中等规模的工程(100-200个源文件)建立索引太慢，常常"Out of
memory"；调试器启动时有常遭遇"No symble 'New' in current context"和"Connot access
memory at address
0x0"之类的错误；代码提示超级慢，10多秒无响应。我是在CPU2.6G,RAM1G的FC5上运行Eclipse3.2.1。大概eclipse的
cdt仅适用于"Hello,world"之类的C/C++工程，但eclipse依然是Linux/Windows平台上开发Java相关工程的首选。
附cscope的使用方法：一般的首先生成cscope.files文件，这个文件里主要是要生成索引的文件列表，一般我都用的find命令生成
（windows下可以考虑使用cygwin），比如我要在当前目录下生成*.c*文件和*.h*文件的索引，那么我可以键入："find .
-name "*.c*" -or -name "*.h*" > cscope.files"，具体的find命令的用法不再阐述了。
生成cscope.files文件之后，在终端键入"cscope -k -q"就可以生成源代码的索引了。
Cscope()解压后contrib/xcscope/xcscope.el是为Emacs/XEmacs准备的。
CEDET(Collection of Emacs Development Environment Tools)网址。
ECB(Emacs Code Browser)网址。
GDB-UI(Emacs Mode for GDB)网址。
注：在安装这些插件的过程中可能有些LISP文件和FC5自带的Emacs的重复，直接覆盖不会有啥问题。
我把cedet和ecb编译后拷贝到emacs资源所在目录（FC5自带Emacs是/usr/share/emacs），然后编辑$HOME/.emacs增加如下设置：
;; Load CEDET
(load-file "/usr/share/emacs/cedet-1.0pre3/common/cedet.el")
;; Enabling various SEMANTIC minor modes. See semantic/INSTALL for more ideas.
;; Select one of the following
(semantic-load-enable-code-helpers)
;; (semantic-load-enable-guady-code-helpers)
;; (semantic-load-enable-excessive-code-helpers)
;; Enable this if you develop in semantic, or develop grammars
;; (semantic-load-enable-semantic-debugging-helpers)
;; Load ECB
(add-to-list 'load-path "/usr/share/emacs/ecb-2.32")
(require 'ecb-autoloads)
;; Load Cscope
(require 'xcscope)
;; Some shortcuts
(global-set-key [f5] 'speedbar)
(global-set-key [f7] 'compile)
FC4上面安装Anjuta2.0.2的过程真是太艰难了。(1)Anjuta2下载页面下方给出了Anjuta2依赖的一些包的名称和位置，但这个提示
并不够显眼（2）把Anjuta网站提供的gdl下载安装后要配置pkg-config依赖的环境变量export
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig(gdl-1.0.pc所在目录)。而某些版本的gdl安装之后并不
产生相应的.pc文件！（3）FC4的glib版本太低，给的链接用Firefox下载不了，用curl搞定了。(4) devhelp 0.11 --> Gtk+2.8 --> Pango with Cairo.
configure Devhelp:
checking for LIBDEVHELP... configure: error: Package requirements (
gthread-2.0 >= 2.6.0
gtk+-2.0 >= 2.6.0
libglade-2.0 >= 2.4.0
libwnck-1.0 >= 2.10.0
gconf-2.0 >= 2.6.0
) were not met.
在FC5上config Source-Navigator 5.2b2一直到5.1.0都失败：
checking if 64bit support is requested... no
checking if 64bit Sparc VIS support is requested... no
checking system version (for dynamic loading)... ../../../tcl/unix/configure: line 6020: syntax error near unexpected token `)'
../../../tcl/unix/configure: line 6020: ` OSF*)'
configure: error: ../../../tcl/unix/configure failed for unix
Configure in /home/kenny/WorkEvnInit/sourcenav-5.1.0/snbuild/tcl failed, exiting.
后来在sourceforge.net此项目的论坛上找到一个patch搞定了，但窗口最大化仍然有问题。
/usr/local/lib/pkgconfig/gdl-1.0.pc
sourcenav在FC4上编译遇到两个错误（在Redhat9上顺利编译）,都是说不支持"-fwritable-strings"选项,把对应Makefile修改一下注释掉这个选项即可.
make[3]: Entering directory `/home/kenny/WorkEvnInit/sourcenav-5.2b2/tix/unix/tk8.3'
gcc -pipe -c -fwritable-strings
make[3]: Entering directory `/home/kenny/WorkEvnInit/sourcenav-5.2b2/libgui/src'
gcc -DHAVE_CONFIG_H -I. -I. -I.. -fwritable-strings
Source-Navigator自2004年3月发布5.2b2以来没有再更新。
http://developer.berlios.de/projects/sourcenav/尝试继续维护它。
Linux上除了SourceNavigator之外，另一个较好的C代码编辑、浏览工具是KScope在http:
//kscope.sourceforge.net/。最新版1.3.4把我的GCC(FC4自带)版本列入黑名单。FC5上安装1.4.0成功。
KScope是Cscope的前端，它的代码导航、外观、语言支持等各方面都较SourceNavigator逊一筹。
Windows上流行使用SourceInsight，不是免费的，且代码导航功能不如SourceNavigator。
GNU GLOBAL is a source code tag system that works the same way across
diverse environments. You can locate a specified object in the source
files and move there easily. It is useful for hacking a large project
containing many subdirectories, many #ifdef and many main() functions.
It is similar to ctags or etags but is different from them at the point
of independence of any editor. It runs on a UNIX(POSIX) compatible
operating system like GNU and BSD.
有人用GLOBAL分析Linux内核以自动生成HTML（例如），其文档功能类似Doxygen，但似乎可以搭配Vim等编辑器来浏览代码。我认为其代码导航功能不如SourceNavigator。
当前Linux平台上的GDB前端有DDD,Insight,KDbg等。DDD是一个非常流行的调试器,Fedora Core
4附带了它。Insight是Redhat的GNUPro开发套件之一,是gdb的Tk包装(版本号与gdb版本号完全一致),可与
SourceNavigator集成。KDbg是gdb的KDE风格的GUI。DDD虽然GUI稍稍难看（Tk和KDE风格我也不太喜欢，基于KDE的应
用在关闭时调用KNotify太慢了），但功能最强。三者中只有DDD支持的后台调试器不局限于gdb；也只有DDD提供了gdb的CLI，这使得其非常
灵活（例如增加一个函数断点，命令break
func就OK，而不像用菜单指定文件名和行号那样烦琐）。Insight调试多线程程序时暂停常常使得Insight失去响应。KDbg是gdb的前
端，可以浏览过去打开的源文件，这是个优势。就像其简介中所说的，你不能期望它能做的比gdb更多，所以它在许多方面都比DDD差：(1)查看变量的值，
如果变量形式较复杂，则鼠标放在其上不能显示其值或者显示其值为0，只得麻烦地写一个监视表达式。(2)不能像DDD的数据窗口那样可视化地显示一个结构
体、数组，必须为特定成员写一个完整的监视表达式。(3)调试过程中不能修改变量值、挪动执行点（这些功能有时很有用）。(4)主窗口以及打开的各个窗口
（本地变量、内存等）在FC5的任务面板上缩成一个标签，切换起来很是费事。
TotalView()号称自己是多核时代地球上最好的多线程/进程调试器。有试用版，不过我想不出来我以后什么时候会觉得gdb不够强。
Valgrind is an award-winning suite of tools for debugging and profiling Linux programs. ElectricFence()声称自己不如 Checkergcc()，而Checkergcc 又由于Valgrind的出现而退役。一句话：当前大家公认Valgrind是最接近IBM商业产品Purify的开源的内存/性能评测工具。
C/C++代码覆盖、性能profiling工具一般基于GNU的gprof和gcov。（还有一类基于模拟器的profiling工具，如IBM
Purify,
Valgrind。KCahcegrind是Callgrind,OProfile等的GUI前端。）我知道的有ggcof,kprof,lcov。
lcov是Linux Testing Project工具之一，见上的工具列表。这儿还有压力测试、WEB Server测试等许多工具。在分类归纳了多种软件测试工具。
运行期间栈以及数据段的溢出比堆溢出更难以发现、定位。绝大多数安全工具聚焦于防止栈溢出覆盖函数返回地址从而阻止了可能的攻击。Avaya
实验室发布libsafe 2.0,增加了防止格式化字符串攻击功能，目前可以保护系统免受两种攻击'buffer overflow' and
'format string'.
Libsafe在自己的strcpy/printf等函数即将导致栈帧处被覆盖时终止程序，从而防止被入侵。其技术思路是：采用
Interposition技术用自己的strcpy/printf等函数替换C标准库函数（ElectricFence也采用此技术替换堆内存相关函
数）；在自己的函数中找到FP位置（函数_libsafe_stackVariableP()），同时判断给定指针是栈上还是堆上；堆上指针直接调用C标
准库函数；栈上指针则在边界检查通过后调用C标准库函数，检查未通过就exit。很多细节限制了其只能用于特定平台Linux并且被保护软件是用gcc编
译。但我的目的是发现所有数组越界错误，要求更严格。可能只有GCC的补丁BoundsChecking(http:
//~phjk/BoundsChecking.html，在SF上有下载http:
//sourceforge.net/projects/boundschecking/)能做到这一点。当前版本(for
GCC4.0.2)仅支持C。我反汇编了它编译出来的executable，发现栈上的字符数组分配由10多条指令加call
__bounds_add_stack_object
来做，在最后多分配了1字节用于保护。堆上内存分配的函数malloc也以__bounds_check_malloc代替。这类补丁最大的问题是产生的
executable运行速度奇慢，尤其是指针操作密集的测试成百上千倍地慢。
尝试了两个例子，效果很好。但webcam工程链接期大量错误，如：
src/protocols/call/sip/src/misc/sipcopy.c:774：对‘__bounds_check_free’未定义的
引用。是不是我的gcc编译不对劲？还是ld不对劲？
Splint is a tool for statically checking C programs for security
vulnerabilities and coding mistakes. With minimal effort, Splint can be
used as a better lint. If additional effort is invested adding
annotations to programs, Splint can perform stronger checking than can
be done by any standard lint.
Flawfinder, a program that examines source code and reports possible
security weaknesses (``flaws'') sorted by risk level. It's very useful
for quickly finding and removing at least some potential security
problems before a program is widely released to the public. Flawfinder
is written in Python.
检查当前目录下（递归地）所有C/C++代码，输出检查结果：
flawfind --quiet --html . >flaws.html
Error: File ended while in string.
除了Splint和Flawfinder之外，常用的开源的C/C++代码静态检查工具还有RATS(http: //www.fortifysoftware.com/security-resources/rats.jsp), ITS4()。此外，Open Source Quality Project（）组织了好几个这方面的项目。
SCons是一个与GNU make, qmake, CMake以及Ant类似的软件构建管理工具。SCons is a
next-generation software construction tool, or make tool--that is, a
software utility for building software (or other files) and keeping
built software up-to-date whenever the underlying input files change.
Scons可以完全替代GNU
Automake/Autoconf。Automake/Autoconf脚本configure的作用有两个：一是平台环境（头文件、数据类型、库等）
检测（交叉编译时这部分很重要），二是定制软件特性（例如Minigui的configure的--enable-clipboard选项表示支持剪切
板）。scons手册的“Multi-Platform Configuration (Autoconf
Functionality)”和“Controlling a Build From the Command
Line”两章分别论述了scons是如何支持上诉功能的。
注意：安装几个版本的scons可能导致混乱：
[root@kenny lib]# scons -v
SCons by Steven Knight et al.:
script: v0.96.95.D002, 2007/02/14 11:01:59, by knight on roxbury
engine: v0.96.1.D001, 2004/08/23 09:55:29, by knight on casablanca
Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation
我发现在/usr/lib下有scons和scons-0.96.92两个目录。我删除scons目录，就解决了这个问题：
[root@kenny lib]# rm -fr scons
[root@kenny lib]# scons -v
SCons by Steven Knight et al.:
script: v0.96.95.D002, 2007/02/14 11:01:59, by knight on roxbury
engine: v0.96.95.D002, 2007/02/14 11:01:59, by knight on roxbury
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007 The SCons Foundation
修改/usr/local/bin/scons文件，使得其输出使用的engine位于何处：
sys.path = libs + sys.path
import SCons.Script
print SCons #自己加的
SCons.Script.main()
输出信息如下：
scons的README指出“Note that, by default, SCons does not install its build
engine library in the standard Python library directories.”
以后别忘了加"--standard-lib"选项。
Java项目的构建现在主要用Ant或Maven来做，这两个工具目前也完全局限于Java项目。我现在不做Java项目，这些东西对我毫无用处，所以就没有深究它们。
技巧：中文环境下gcc给出的warning和error都是中文的，不便于在网上找资料，也不便于在Emacs查看。怎样让gcc输出英文的信息呢？一
个麻烦的办法就是每次运行scons之前先执行"export
LC_ALL=en_US.UTF-8"。其实可以这么做：在SConstruct文件设置好编译环境env之后，在导出env之前，添加如下一行以修改
编译过程中的locale：
env['ENV']['LANG'] = "en_US.UTF-8"
SCons可以结合distcc ()和ccache节省大型软件项目的编译时间。
CMake()
是一个Makefile生成器（作用相当于GNU atuotools链），它能为许多native build system(如GNU make,
MS VC6, MAC OS Xcode等)生成配置文件。KDE4这个大型软件初期尝试了SCons以解决GNU
atuotools链的各种弊端，不过最终选择了CMake。其中的缘由请看"Why the KDE project switched to
CMake", 。
"跨平台的编译工具，其中最有名的两个是 CMake 和 SCons。CMake 和 SCons大概代表了新一代跨平台编译工具的两种方向。第一种
(CMake) 是延续并改良传统 automake, autoconf 工具链，将之合为一体，但最终仍然生成 Makefile, Visual
Studio 的 .sln，Xcode 的 .xcodebuild 文件，依赖现有编译工具 (make, nmake, vcbuild,
xcodebuild) 来编译；第二种则是完全消除现有编译工具的调用，直接调用编译器，scons
就属于这一类。从人气上来说，反倒是走改良路线的 cmake 比 scons 好一些..."
按照《Building Embedded Linux
Systems》极其详尽的指导，为嵌入式系统开发构建GNU交叉工具链也很困难：gcc/glibc/binutils/kernel版本之间的配合，
特定版本的特征（如GCC3.2开始应该这么做而不是那么做），还要考虑补丁...手工来做非常耗时且不大可能成功（碰到问题看文档和使用Google也
不一定能搞定）。用crosstool（，
另外在http: //有一些解释、补丁等），只需要你有个Linux
PC能上网，一个命令（如demo-arm.sh）下去就行。有时间可以深入研究一下这个工具。Building a gcc / glibc
cross-toolchain for use in embedded systems development used to be a
scary prospect, requiring iron will, days if not weeks of effort, lots
of Unix and Gnu lore, and sometimes willingness to take dodgy shortcuts.
Linux内核的ARM补丁、ARM工具链都可在http://www.arm.linux.org.uk/developer/上找到，这是Linux ARM架构的最权威站点。 另外可能还需要特定芯片厂商提供的补丁，例如3615使用的TI DM320有内核补丁设置了各设备在Flash的地址。
注意：(1)对一个项目而言，升级交叉编译工具链后，制作的ramdisk内也要以新的C动态库替换掉老的，否则可能导致兼容性问题如程序运行不起来。
(2)要使得toolchain识别用户添加的库，把库放在arm-linux/arm-linux/usr/lib。为了运行时能找到这个库，制作的
ramdisk也必须包含这个库。(3)如果硬件平台没有浮点支持，所以在crosstool的arm.dat文件最后添加如下两行：
GCC_EXTRA_C和GLIBC_EXTRA_C；或者不使用demo-arm.sh而是demo-arm-softfloat.sh(注意这两个脚
本可能在GCC版本方面并不同步)。在交叉工具链完成后可以用"arm-linux-gcc
-v"查看配置情况。(4)默认的目标是arm-unknown-linux-gnu，可以在arm.dat中将TARGET设置为"arm-
linux"使得编译出来的GCC名字为arm-linux-gcc。
编译Linux内核，如果目录层次过深，可能出现如下错误：
scripts/mkdep -- `find
/home/kenny/svn_LRSH/ipcam/trunk/LR3615_BII/kernel/linux-2.4.26_LRSH/include/asm
/home/kenny/svn_LRSH/ipcam/trunk/LR3615_BII/kernel/linux-2.4.26_LRSH/include/linux
/home/kenny/svn_LRSH/ipcam/trunk/LR3615_BII/kernel/linux-2.4.26_LRSH/include/scsi
/home/kenny/svn_LRSH/ipcam/trunk/LR3615_BII/kernel/linux-2.4.26_LRSH/include/net
/home/kenny/svn_LRSH/ipcam/trunk/LR3615_BII/kernel/linux-2.4.26_LRSH/include/math-emu
\( -name SCCS -o -name .svn \) -prune -o -follow -name \*.h ! -name
modversions.h -print` > .hdepend
/bin/sh: scripts/mkdep: 参数列表过长
make: *** [dep-files] 错误 126
可以把内核代码放到浅一些的目录，或者为内核代码根目录做个软链接。
为3615/3621编译Linux内核时，注意修改内核代码drivers/mtd/maps/dm320map.c。
[使用distcc 缩短编译时间]distcc is a program to distribute builds of C, C++,
Objective C or Objective C++ code across several machines on a network.
distcc should always generate the same results as a local build, is
simple to install and use, and is usually much faster than a local
compile.
The main feature required by distcc is that the compiler must be able
to run the preprocessor separately, and then compile the preprocessor
output from a file. This was a basic part of the original design of C,
but some compilers seem to have lost the ability to do this.
Secondarily, distcc is currently hardcoded to suit gcc's behaviour and
command-line syntax, so only compilers that act like gcc will work.
This could in principle be changed.
patch文件中指令都是面向单个文件内容比较的：增加的文件所在目录不存在则创建它；打补丁后空文件及其所有空的祖先目录都被删除。请看patch手册中选项"-E"和Caveats一节。
Tips for Patch Producers
To create a patch that changes an older version of a package into a
newer version, first make a copy of the older and newer versions in
adjacent subdirectories. It is common to do that by unpacking tar
archives of the two versions.
To generate the patch, use the command diff -Naur old new where old
and new identify the old and new directories. The names old and new
should not contain any slashes. The -N option lets the patch create
and remove files; -a lets the patch update non-text files; -u
generates useful time stamps and enough context; and -r lets the patch
update subdirectories. Here is an example command, using Bourne shell
syntax:
diff -Naur gcc-3.0.3 gcc-3.0.4 > patch_gcc_304_to_303
Tell your recipients how to apply the patches. This should include
which working directory to use, and which patch options to use; the
option -p1 is recommended. Test your procedure by pretending to be a
recipient and applying your patches to a copy of the original files.
For example, place patch_gcc_304_to_303 at the directory in which
gcc-3.0.3 lies, using Bourne shell syntax:
cd gcc-3.0.3
patch -p1 < ../patch_gcc_304_to_303
Kompare是KDE自带的一个文件/目录比较工具，比较大目录太慢了，也没有合并功能。我上网了解到在这方面的好工具有Kdiff、Meld和
xxdiff。Meld的没有做汉化，许多菜单、按钮的文字显示不出来或者是乱码。xxdiff还没有尝试过。Kdiff3还有windows版本。
Kdiff3 is very good for large merges, automatic merge facility.
Meld is a visual diff and merge tool. Meld is written with the excellent pygtk toolkit.
kdiff3-0.9.90-1.fc.i686.rpm
要求libstdc++.so.6(GLIBCXX_3.4.6)，对应的FC4平台RPM是libstdc++-4.0.2-8.i386.rpm,但
FC4光盘上只有4.0.0，网络速度太慢，下载不了！:(
kdiff3-0.9.89把我的编译器列入了黑名单。最后用0.9.88终于顺利安装了。运行起来感觉不错！
Subversion（简称svn）是经典的开源的版本控制系统cvs的替代物。有个工具cvs2svn可以转换CVS库到SVN库。
SVN客户端GUI非常丰富。Windows上最流行TortoiseSVN()，好用且功能强。其他大多是跨平台的，以下是我尝试过的：
RapidSVN (基于wxWidgets，在FC6编译失败，只得用yum安装。在中文环境下总是工作不正常)
KdeSVN (可yum安装，功能少，在中文环境下工作不正常)
QSvn (要求QT4且功能少--尤其是缺乏Blamme功能)
SmartSVN (仅提供试用版，基于Java--自然内存和速率方面表现差。注意它要求使用SUN的JRE)
我推荐WorkBench（pysvn附属物，基于wxPython）。它功能和速度方面都不错，并且在中文环境下能很好地工作。注意：(1)如果已安装
的wxPython版本在wb_main.py选择的wxPython版本列表内，则需要添加进去。(2)如果WorkBench工作不正常，很可能是
pysvn与系统SVN库有冲突。
StatSvn基于著名的StatCvs的SVN版本，开源，以Java编写。它能够对整个SVN库做统计，包括：每作者提交数、拥有代码行数等等。试用
了一下，感觉很不错！（StatSvn手册指出：由于SVN日志文件的特性，第一次统计较慢。我针对LR3615_WEBCAM工程[10万多行]第一次
统计，耗时70多分钟。）另外要注意：FC5默认JRE（即gij）没有提供Graphics2D等库，这将导致JVM抛出异常。安装SUN提供的
JDK1.5.0即可解决此问题。
[kenny@kenny statsvn-0.2.0]$ java -jar statsvn.jar /home/kenny/sw_3615/svn.log /home/kenny/sw_3615
mpy-svn-stats: Very simple and easy to use Subversion statistics generator written in Python. ()是另一个Subversion库分析工具。SipX项目的统计信息（http: //）就是由此工具生成的。
ViewVC是一个基于web的CVS、SVN代码仓库浏览工具。它最早是从cvsweb发展而来的，cvsweb是用Perl编写的，
viewvc原作者Greg
Stein发现很难在此基础上扩展新的功能，于是用Python重新实现，并命名为viewcvs。后来又加入了对SVN代码仓库的支持，为反映这一变化
viewcvs重命名为viewvc。viewvc可以以独立的程序运行(standalone.py)，也可以以cgi方式运行于支持CGI的web服
务器，还可以以ASP模式运行于IIS，以mod_python模式运行于Apache。viewvc通过本地文件系统访问代码仓库，所以它必须安装在运
行CVS或SVN代码仓库的同一服务器上。运行viewvc需要很多第三方软件，具体需要的依赖软件取决于启用功能和运行平台两大因素。viewvc除了
支持CVS代码仓库浏览功能，还支持
1)SVN代码仓库浏览功能
2)代码语法加亮、颜色标注
3)CVS代码修订历史图形显示
4)CVS代码代码提交动作的记录、查询
此外还有FishEye（）等商业的代码库分析工具。
程序代码美化工具astyle可美化C/C++/Java。astyle有几个成套的的风格定义：ansi java linux
kr...不必记住复杂的缩进具体选项。indent（gcc附带的一个标准工具）只能美化C代码。专门针对Java代码的有CheckStyle（免
费，）和Jacobe（商业，http: //）等。
astyle 1.19有个BUG：如果#ifdef 下一行以{开头，则{被调整到#ifdef行最后，这必然导致编译失败。
indent也不完美：(1)处理dspcode.h类似文件时间极长，把数组每一项单独作为一行导致头文件行数极多。Frank说处理
dspcode.h类似文件之后导致编译失败。(2)在#else之后自动加了/*，随后多了一行*/。(3)有时候格式化比较乱甚至导致编译失败。
Windows平台上有试用版的SourceFormatX。
结论：不要企图把整个工程的源代码一次性格式化，哪个C文件格式实在太乱了再说。
#/bin/sh
# -kr Kernighan & Ritchie style
# -nbad -bap -bbo -nbc -br -brs -c33 -cd33 -ncdb -ce -ci4 -cli0
# -cp33 -cs -d0 -di1 -nfc1 -nfca -hnl -i4 -ip0 -l75 -lp -npcs
# -nprs -npsl -saf -sai -saw -nsc -nsob -nss
# -nbad The '-bad' option causes `indent' to force a blank line after every
# block of declarations. The `-nbad' option causes `indent' not to force
# such blank lines.
# -cliN Case label indent of N spaces.
# -bliN Indent braces N spaces.
# -cbiN Indent braces after a case label N spaces.
# -nut Use spaces instead of tabs.
indent -kr -bli0 -cbi4 -nut $1
