Linux系统——C/C++开发工具及环境搭建

首先，我们是要在Linux下进行项目开发，让我们把windows“拆了”，装个Linux也是不可能的，会带来很多的不便，所以我们首先需要在虚拟机上安装Linux操作系统，我本次用的是CentOS，它也是Redhat Linux的产品中一种。对于虚拟机上Linux的安装网上的资料很多，相信我们都能自己独立完成安装。
接着，我们需要下载Linux下的开发工具，以下是工具的说明及下载地址：
1、Cmake（构建工具）
CMake 是个跨平台的自动化构建系统，它通过用组态文档来控制构建过程（build process）的方式和 Unix 的Make 相似，只是 CMake 的组态档取名为 CmakeLists.txt。Cmake 并不直接构建出最终的软件，而是产生标准的构建文档（如 Unix 的 Makefile 或 Windows Visual C++ 的 projects/workspaces），然后再按照一般的建构方式进行使用。
下载地址：http://www.cmake.org/cmake/resources/software.html
学习文档：http://sewm.pku.edu.cn/src/paradise/reference/CMake%20Practice.pdf

2、log4pp(Linux下日志记录工具)
学习及工具下载地址：http://log4cpp.sourceforge.net/

3、CxxTest(Linux下C/C++工程单元测试工具)
学习及工具下载地址：http://cxxtest.tigris.org/

4、Gdb（Linux下C/C++调试工具）
学习及下载地址：http://www.gnu.org/software/gdb/

为了书写程序和与Linux交互方便，我们还需要以下辅助工具：
1、Eclipse+Uniwin（远程代码代码同步windows到Linux）
2、SecureCRT（相当于Linux下终端），可以在windows下控制Linux
3、Linux_scp （用它来进行linux与windows之间的文件传输）

我这全是 Linux 环境开发，我就大致介绍以下我们这里的现状吧：

编辑器：
vim 用户：45%
eclipse 用户：30%
kscope/kate/kdevelop 用户：15%
emacs 用户：5%
win虚拟机+source insight用户：5%

说明一下：
三个k字头的其实内核都是 kate 的内核，emacs的用户一般是超牛人。vim 用户是主流用户。
source insight 的致命缺点在于不支持 utf-8，而我们会规定所有项目的源代码使用 utf-8 编码。显然，大多数人认同使用 utf-8 是个好习惯，因而 si 的用户必然被限制无法在代码中使用和阅读中文。
其实大多数编辑器不存在明显的功能残缺（除了不支持utf-8的source insight），但是很多功能你是需要有团体互相交流才懂的，明确的说 SI 的几乎所有功能都可以在 vim/eclipse 中实现，对于 vim/eclipse，绝大多数需求在我们这里可以通过互相交流而弄懂，所以自然滚雪球一样越来越多。

编译环境：
统一配发的工具链，编译时使用 chroot 环境。关于这一点没什么可说的，编译环境必然需要所有人全部统一，无论你使用什么发行版。

版本控制：
有很多项目，通常使用 svn/hg/git。原先使用 svn 的为主，后来都转到了 hg，目前大多数项目使用 hg。至于 git 因为使用配置太过复杂，目前只有一个项目组使用。对于存在 svn 历史积淀的项目组来说，hg 确实是一个远超越 git 的神器。

调试：
从 Linus 大神开始，printf 就一直是调试利器，上面虽然没有一个人提到 printf 是调试利器，但没人敢不承认它。——关于这一点在现实中会存在许多变种，例如可以定制自己的宏实现分标志，分级别，重定向到 syslog，或者文件，远程 udp socket，等等。相关的工具打造好了之后，你获取信息会很精准而方便。我个人经常使用 udp socket 来接受日志输出。

附注：
Subversion
Subversion 是群英汇支持的最重要的产品，我们服务的大多数客户，都或多或少的选择了我们的版本控制服务。群英汇为客户提供Subversion版本控制服务，从培训、应用部署、系统整合到售后服务、技术支持。

我们公司的部分项目使用了Subversion版本控制系统，如：
pySvnManager：托管在SourceForge上
FreeMind-MMX: 托管在SourceForge上
WordPress的CoSign-SSO插件：位于官方的Subversion库中

我们公司内部的开发在2007年以前，也主要使用Subversion，但是之后，我们的代码库逐渐的向分布式版本控制系统迁移：
先是Hg：Hg是水银的化学元素符号，全称为Mercurial。
后来是Git：Git 是 LinusTorvalds 继Linux后的又一个伟大发明，为全人类的另一个伟大贡献

Hg/Mercurial
Hg走入我们的视线，是因为我们研究的项目都一个一个脱离Subversion阵营，转向Hg，使用Hg作为各自项目的版本控制工具。其中一个我们主要研究的项目是：MoinMoin维基。

使用Hg后，困扰我的问题迎刃而解，就是：
我们的软件开发模式是基于成熟的开源软件进行定制。项目的原始代码库称为上游，我们自己的代码库称为下游；
使用Subersion，我们采用Subversion的Vendor分支（或称卖主分支）来管理我们的代码,一但上游软件软件出现新的版本，我们代码的迁移就成了最让人头痛的事情，可能好几天都不能搞定；

Hg可以很好的解决这个问题，原因在于：
Hg是分布式版本控制工具，整个代码库都在本地，浏览变更历史速度超快，实际上是本地访问，不再受制于网络。这样我们就可以更快的建立和上游版本库的同步，尽早尽快的解决代码合并问题，而不是要等到新版本发布；
Hg的最佳拍当MQ！简直就是为我们的开发模式所设计的。Subversoion的卖主分支和MQ相比就好像马车和火箭的对比。
Hg简单，并且使用习惯和Subversion非常相似，这也是为什么我们公司的版本控制系统在转向 Git 后，仍有部分项目在使用 Hg的原因

群英汇的Hg开源代码库:
http://bitbucket.org/ossxp_com/

Git
有了Hg，为什么还要用git？
和Subversion代码库同步的需要。
虽然svn可以镜像远程代码库，但镜像库不能提交;
Hg不支持分支，因此无法完全克隆一个Subversion代码库
Git有着完备的分支支持，可以将远程svn库镜像为一个本地的git库，而且可以提交甚至远程提交

Git速度更快。如果你用过git和hg，你就会对我说的有所感觉：
Hg提交/克隆/push/pull，我经常对自己无所事事 <[if gte vml 1]> 而感到恼怒，感觉就像傻子一样，完成了多少？1%还是99%？
Git速度超快不说，整个过程有着详尽的提示，真是体贴备至。 <[if gte vml 1]>

Git＋Topgit很好的支持上下游的协同开发
Hg的MQ虽然很好，但是Git有Topgit，而且Git的rebase功能更成熟
MQ可能更适合单人开发，但是没有办法对补丁之间建立依赖关系
Topgit采用分支来管理补丁，而且可以在分支之间设置依赖，可以是代码更整洁