eclipse cdt 搭建 c/c++ 开发环境的总结

http://blog.csdn.net/yang3wei/article/details/7624465

一口气转了很多篇文章，本来最近事情很忙，

是准备将在 eclipse 中搭建 c/C++ 开发环境的事情放在后面的，

无奈还是没忍住，今天一不小心就把这事儿给办了~

eclipse 是如此之优秀，我简直深陷其中无法自拔，

现在，java，actionScript，c/C++，python 这些编程语言我都能够在eclipse中进行开发了。

现在的心情，毫无疑问是非常之舒畅的。

至于 objective-c，还是在 Xcode 里面老老实实地呆着吧，

XCode 其实也很不错，和 eclipse 可谓是不遑多让，

只不过在兼容多门编程语言方面做的不是很好。

以前的 XCode 好像是可以支持 c/c++，java 等语言的吧（现在貌似也支持c/C++）~

现在的 XCode 经过了阉割，安装包的大小由 3。多G变成了现在的1。6G，

功能上自然是削减了不少。功能是为什么会做缩减，猜不透苹果的想法.

不过 XCode 依然能用来进行 objective-c 的书写，也算是彻底回归了老本行，

让人有一种回归本质的感觉，其实 c/c++，java等还是n多的ide可以选择的。。。

今天弄 eclipse cdt 花了我很长的时间。

倒不是说下载带 cdt 的 eclipse 版本要花费多长的时间，100多MB而已，

虽然我网速不行，不过还是没用多久就给下载完毕了。

我本机里面之前已经有一个 eclipse了，也是 helios的，

后面觉得两个 eclipse 有点儿鸡肋，就直接在之前一直使用的 eclipse 里面安装了 cdt 的功能更新。

这样做了以后，便算作是将好几种编程语言的开发环境都集中到了之前一直使用的那个 eclipse里面。

感觉还是相当不错，换不同的语言做开发，简单的切换一些 ide视图就可以了。

如果觉得各个不同语言的项目混杂在 workspace 里面，还可以为各个不同的语言建立一个独立的workspace，

使用的时候，随意去切换一下便行了，总之，用起来比较方面咯~

不过，在弄 cdt 的时候也是遇到了不少细碎的问题，其中的一两个问题甚至花费了我大把的时间，

写这篇博文的目的也是将其间遇到的各种蛋疼的问题给记录下来，给今后一个参考~

恩，其实一些比较简单的问题在之前转载的一些文章中都已经有所体现了。

思忖再三，还是将最最棘手，坑了我n多时间的这个大头给亮出来晒晒：

最主要的问题便是，我若新建了一个项目，这个项目的构成类似于 Box2D 的 Testbed，

该如何将 glui，glut，box2d 这些轻量级复用框架的源码模块组织到我的项目中来呢？

这个我问题我在网上搜了很久，没有找到最契合我需求的答案，

可能还是因为 eclipse cdt 用的不是很广泛，或者是用cdt 弄开发的都太过低调，没有留下多少有价值的文字记录。

闲话不多说，也不卖关子，直接捡最最重要的一些东西罗列下来：

1。右键点击项目-》属性（command+i）-》“C/C++ build” -> Settings->ToolSettings->

GCC C++ Compiler -> Includes:

"${workspace_loc:/TestBox2D/libs}"

上面这个字符串是浏览选取项目中的 libs 目录后自动生成的。

类似于 EL 表达式，意思也很明了，就是说编译器在编译的过程中会检索这个目录下面的 。h 头文件。

其实，经过我的测试，C/C++ Build 中的这个设置

和  C/C++ General->Paths and Symbols->Includes->GNU C++ 中的设置是相关联的~

将下图中 includes->include directories 中的 /TestBox2D/libs 去掉之后，

之前那张图中的 "${workspace_loc:/TestBox2D/libs}" 也会被同时抹除掉。

反之，将之前哪张图中的 "${workspace_loc:/TestBox2D/libs}" 去掉之后，

后面所说的那个位置的那行以紫色图标开头的 “/TestBox2D/libs” 条目也会被抹除掉。

因此，上面所谈及的两者是息息相关、相依相存的。

参照下面贴出的这张图来对我所阐述的意思进行正确的了解：

至此，将项目clean一下，之前所报出的找不到 Box2D.h 头文件

或找不到 b2World.h、b2Body.h 等其他属于 box2d 源码模块 头文件的编译错误就不会再出现了~

不过问题还是没有解决。下面将会遇到一个新的编译错误，那就是：

在 main.o 对象文件中找不到 b2World，b2Body 的定义

(main.o 包含了 main 方法，.o 文件是 cpp 文件编译后生成的文件类型)。

这个问题我在网上查了下，很快边找到了原因所在：

那是因为，前面的操作仅仅是让编译器知道了 box2d 源码模块头文件的位置，

至于这些头文件的具体 .cpp 实现，虽然是和头文件放在一起的，但实际上是不会被编译的。

据我猜测，只有被归类为代码源文件的目录，其中的 cpp 文件才会编译到。

这点并非我信口胡诌，因为我在控制台下面确实没有看到有 b2Body.o , b2World.o 等文件被编译出来。

这个便足以说明问题：box2d 的 cpp 源文件没有参与编译过程。

问题既然已经找到，那么解决办法也是信手拈来了：

将box2d 源码模块所在的根目录划归为 “源代码文件夹” 即可！

下面是项目的目录结构以及使用到 box2d 物理引擎的程序顺利执行的截图~

总的来说，这次花费了那么多冤枉时间主要还是因为对 C/C++ 的

#include <Box2d/b2Body.h> 这行预处理命令了解的不是很透彻，或者说是以前了解了，但是很久没用又给忘了。

#include <abc/def/fuck.h>  和  #include “test.h” 的含义是不一样的，这点众可以去问 google 大神，

时间过太久，我也只是退化到只能意会不能言传的地步了，说的不对怕误导了别人。

恩，不说这些丧气事儿了。谈一谈 eclipse cdt 的感官体验吧：

对比于  XCode 编译 objecive-c 与 c/C++ 混编的项目，个人感觉还是 XCode 的编译效率要高一点。

给我的感觉就是，eclipse cdt 仅仅编译一个 box2d 源码模块就让我等的有点儿心烦了。

说到这点上面，苹果现在已经展开硬翅膀准备脱离 GCC（GNU Compile Collecion ）了，

苹果弄了一个 llvm。llvm与GCC 的区别我不是很清楚，但是我知道的是，

总有一天等到时间成熟了，apple 会将 llvm-gcc 编译组过渡为纯粹的 llvm。

一年以前在深圳的时候，那时候我用的是 windows，我还清楚的记得，

我看到 GCC 号称能编译 N 中编程语言那时候自己脸上兴奋的表情，

down 了不知道多久（GCC 很大的），终于是把一整套 GCC 给搞到自己电脑里面来了。

其实后面也没怎么用到，就用了g++，gcc 编译了一些 c/C++ 源文件，

其他的程序语言都没怎么去涉及到。后面又一次电脑出问题了，ok，还原之后什么都没了- -、

现在用的是 Mac ，基于 Unix 的变种，非常非常优秀，适合做科研的系统，

不再是操蛋的 windows，给我的惊喜就是 ：

Mac 内置了 python, java, Gcc, 以及苹果自己推出的 LLVM 编译工具集。

在 Mac 上面，原来在 windows 上面要通过 n 久的下载才能获得的开发环境，

Mac 就直接给内置上了，从这点来看，不得不说 Mac 做的 比 windows 要好太多了。

有人说 Mac 操作简单，用多了就傻了，

其实只要稍微有进取心一点，mac 是比 windows 要更加适合用来做程序开发、用来学习操作系统的。

纯属个人看法，愤怒者果断来拍砖，收工~