zoukankan      html  css  js  c++  java
  • 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采用分支来管理补丁,而且可以在分支之间设置依赖,可以是代码更整洁


  • 相关阅读:
    【C/C++】Dijkstra算法的简洁实现
    【数学建模】图论方法的数学模型
    【数学建模】模糊数学模型详解
    【数学建模】基于问题的线性规划和混合整数规划求解
    【机器学习】非常全的机器学习资源汇总
    【数据结构】数据结构中的各种树详解
    【数据结构】八大排序算法
    【数据结构】七大查找算法
    【数学建模】MATLAB语法
    【论文阅读】Sequence to Sequence Learning with Neural Network
  • 原文地址:https://www.cnblogs.com/sun-frederick/p/4763582.html
Copyright © 2011-2022 走看看