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

 

首先，咱们是要在Linux下进行项目开发，让咱们把windows“拆了”，装个Linux也是不可能的，会带来不少的不便，因此咱们首先须要在虚拟机上安装Linux操做系统，我本次用的是CentOS，它也是Redhat Linux的产品中一种。对于虚拟机上Linux的安装网上的资料不少，相信咱们都能本身独立完成安装。
接着，咱们须要下载Linux下的开发工具，如下是工具的说明及下载地址：
一、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

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

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

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

为了书写程序和与Linux交互方便，咱们还须要如下辅助工具：
一、Eclipse+Uniwin（远程代码代码同步windows到Linux）
二、SecureCRT（至关于Linux下终端），能够在windows下控制Linux
三、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采用分支来管理补丁，并且能够在分支之间设置依赖，能够是代码更整洁