非常有幸,在老师的指引下我和开源世界结缘...倾心于其鲜活的生命力,源源不断的创新力,但是事情往往是有两面性的，在开源库来讲，就是他的使用还是比较麻烦，不像那些商业软件那样帮你打点好一切，在这里，一切你想要的都要自己去搞定，或许你将为打造一个开发环境而耗费一天，甚至一个礼拜。
下面我就把我在编译这些库的过程和感受作一个记录，今天刚完成osgEARTH的编译，为了完成osgEARTH的编译我用了整整一天一夜的时间，在这个过程中大部分的时间都用在寻找支撑库和第三方库，其次就是等待编译过程结束。
如果要给开源库作一个分类的话，那么我目前接触过的有友好型的，一次config，一次make就能解决问题，像Qt，OpenCV，PCL这样的，大量的第三方库都会提供给你；自立更生型，告诉你用到了哪些库，自己去找，自己编译，要么使用，osgEARTH就属于这种的，同样还有OSG等；会意型，这或许是开源的最高境界了，即便官网上也不会贴出如何编译源码的步骤，那好吧，全靠自己理解了。目前这一类的好像都比较小，zlib，sqlite这样的。不论哪种，首先应该找到相关的文章，在编译osgEARTH时我就根据download参考了一下这三篇文章：
1，OpenSceneGraph在Visual Studio 上安装，链接点击Support/PlatformSpecifics/VisualStudio –osg
2，另外一篇来自博客园osgearth+vs2010安装
3，还有来自github的Cook Book OSGE Installation · updraft/updraft Wiki · GitHub
在编译CGAL的时候我就参考了如下几篇文章：
1，Installing CGAL and related programs on Windows operating system
如有疑问还可以参考我的博客和装CGAL与解决"QWidget: Must construct a QApplication before a QPaintDevice". 问题，要更多文章的话可以参考CGAL编译配置
最好就是里列一个表，把链接和需要的支撑库都列清楚。然后对号入座，我在编译osgEARTH的时候真的被那些支撑库搞得头昏脑胀，因为我发现，这个库的支撑库还是一种开源库，那么你又要去编译，至少有三重啊！！比方说，osgEARTH需要osg的支持，osg则需要gdal的支持，gdal的运行需要proj4的支持，像CGAL中，三维显示需要QGLviewer，QGLviewer需要Qt支持，Qt又需要其它的类似sqlite等开源库的支持，吧啦吧啦。每一个环节都不能有差错，不胜其烦。
而像Qt，PCL和OpenCV这样的库在配置上给用户带来了很大的方便，只需运行下载好的安装包针对特定的编译器配置路径和一些必要的参数即可。然而如何应付这些
首先，获取支撑库：
osgEARTH需要的支撑库列表在osgearth+vs2010安装中有详细列出，这里不再赘述。
CGAL的支撑库列表
Boost，Qt4，zlib，GMP，MPFR，其中后两个CGAL帮我们搞定了，你也可以通过CGAL的下载目录找到它们。 VirtualPlanetBuilder支持库列表
GDAL，OSG，zlib，……
osg的支撑库列表可以在这里找到：
OpenCV和PCL等都是可以在其下载网站上下载到第三方库的，这里也就不一一列出，但凡找支撑库，我们可以通过各种途径去下载，并集中到我们的根目录下来一一编译，得到支撑库，Windows环境下，一般是dll、lib和h头文件通常被放置在bin、lib和include文件夹下。ok，在我已经完成第二步之后，就要进入到编译环节，这是一个煎熬的过程，有等待有报错…… 编译过程中有许多问题要注意，大多数集中于如何处理路径的问题上，设置路径与目标（预想）路径是否匹配，其次是库的版本，尤其是Release和Debug之间出现了差错，即使可以完成配置，在编译器上也会给出一大堆的错误。还有一些主要是开发者的失误。在这一过程中我们需要引入新的工具，CMake，它可以通过CMakelist，用户填入的表项来创建sln文件，即集成路径，把所有的路径都配置给编译器。
1、osgEARTH需要GDAL的支持，但是GDAL在编译完成后并没有很清晰的标记debug和release，参考github文章中的说明最好使用gdal_i.lib作为debug链接库，而动态库就没有什么要紧的。
2、在应用GEOS编译osgEARTH的时候也存在同样的问题，一般还是用libgeos.lib作为debug的链接库；当然，如果你下载了预编译的支持库，那么就会有明确的D标记作为debug下的链接库如osgearthd.dll，没有标记的一般是Release库osgearth.dll。
3、CGAL在编译的时候要用Qt和Boost我用了Qt 4.8.0 RC和boost 1.4.8结果这两个库冲突了，后来google了一下，发现Qt在它的moc工具代码有问题，在Qt4.8.0 的路径下找到../src/tools/moc/main.cpp修改第192行，在此处加一句pp.macros["BOOST_TT_HAS_OPERATOR_HPP_INCLUDED"]; // rh#756395 ；然后自己重新编译一遍Qt就好了。 4、默认情况下GDAL的编译使用的是sln文件目录下的nmake.opt作为路径配置参考的，那么我们需要通过修改其中的参数来完成订制，一般GDAL_HOME这个变量会比较重要，关系到编译结果的位置，顺便在默认的情况下，GDAL是不会产生include和lib文件夹的，用户可以自行创建，将alg，apps，brige，frmts，gcore，ogr，port等文件夹下的.h和.lib文件分别放入include和lib中。还有一个重要的参数是MSVC_VER 如果是Visual Studio 2010的话就是1600，向下的.net VS依次减100，作为版本号。
5、在使用sqlite3的时候要注意它本身没有包含.lib文件，在VS prompt 命令行下，导航到sqlite3所在的目录中，使用 LIB /DEF: sql3.def处理，完成之后就可以在相同的文件夹下看到sqlite3.lib。
6、在使用Visual Studio 2010构建这些库的时候还可以使用build菜单栏下的batch build，在弹出的对话框中选择ALL_BUILD项目就可以完成该解决方案下的所有项目的构建，如没有这个项目，用户就必须自己去勾选了，在构建完了之后用户还可以通过构建INSTALL项目完成安装过程，这个过程会产生一个标准的文件目录，包含了bin，include和lib。当然，有些项目并没有这一项，GDAL就是。
7、使用CMake的时候有一点需要注意，如果需要额外加入项目，比如ZLIB_INCLUDE_DIR和PNG_LIBRARY等项目，而在此之前你已经configure了，那么务必在设置之前将CMake关闭，将构建目录下的CMakeCache.txt删掉，重启CMake，在重新configure之前，将所需的目录添加到CMake中。BTW:介绍一下CMake这个工具，在构建开源库的过程中，你可以看到各式的凌乱，CMake主要的功能就是将所有的路径构建好，然后交给编译器处理，避免用户直接手动配置编译器路径，这和makefile有异曲同工之效。在使用cmake时只要将工程中CMakeLists.txt文件拖放到CMake_GUI中，点击configure按钮并在弹出的对话框中选择对应的编译器，Visual Studio 10代表visual studio 2010，进行配置知道通过构建，窗口显示"configure done"字样，然后点击generate按钮就可以生成.sln文件。
8、在构建VirtualPlanetBuilder时，会出现一些异常，这是因为写这个代码的程序员漏了一个头文件没有包含进去，而实际上在新代码中这个没有包含的支撑头文件被用到了，故而我们需要在../src/vpb/SpatialProperties.cpp中加入#include <osgDB/fstream>即可
9、牢记一点，无论如何都要让编译器找到那些支撑库，不管使用CMake，makefile还是编译器中设置VC++ directory和Linker下的Input项。这些目前都只是在Windows平台下实践过，至于Linux下怎么实现我想与以上几点应该差不多吧。
10、最后，顺便说一句，如果E文不是很好的话，在此我提供一个网址，是微软的英库技术支持的一个翻译网页的网页，你只要按照步骤将这个网页作为收藏，以后遇到不懂的语言都可以通过它来翻译，当然如果你是IE(9以上）的铁杆用户，你也可以在网页上右键单击选择 使用必应翻译 即可翻译成中文，万试万灵，就是有点生硬，加上一点自己的理解相信没问题的。
收关
在一个运行库编译结束要记得去验证自己编译的库是否可用，能否支撑程序运行，这个技术难度不是很大，往往就是有很多依赖库不在本文件夹下，程序和动态库是分开的，最笨的办法是把它们复制到一起，这样的话，计算机就会多出很多冗余文件。据说还有一种办法是设置path参数，就是在导航到运新目录下，命令行中使用set path=%PATH%;bin_dir_for_use使用。点击打开链接
我构建完成的一套osg和osgearth环境。如果源文件缺失请自己下载解压一下。
