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採用分支來管理補丁，並且能夠在分支之間設置依賴，能夠是代碼更整潔