简介一份专为VS2013 x64平台编译的Ceres Solver库资源面向需要在Visual Studio 2013中处理非线性最小二乘问题的C开发者适用于计算机视觉、机器人、三维重建等数值优化场景。压缩包大小348.67MB内含2000个文件主体为Ceres及依赖库的源码c、h、cpp、cc和编译生成的obj、lib、dll、exp等库文件同时包含大量用于文档说明的图像与示例数据可在VS2013工程中直接配置引用。已有390人学习下载。该资源省去了手动获取Eigen、glog、gflags等依赖并逐一编译配置的繁琐过程拿到后只需将头文件目录与库文件加入链接器设置即可启用自动微分、损失函数及多种线性求解器帮助开发者快速开展大规模非线性优化开发。 刚开始接触Ceres Solver那会儿我还在用VS2013配x64平台编译这个库前前后后踩了一堆坑折腾了差不多一个周末才把整个流程跑通。最近看到还有人在这上面卡壳我就把自己在VS2013 x64环境下编译Ceres库的过程和心得整理出来希望能帮你少走点弯路。Ceres Solver是谷歌出的一个开源C库专门用来解决非线性最小二乘问题。做SLAM、三维重建、相机标定、传感器融合这些方向的同学应该都不陌生它内部集成了自动求导、数值求导这些工具配合LM算法、Dogleg算法做优化求解非常方便。但是Windows下编译这玩意儿特别是VS2013这种老版本工具链那真是考验人的耐心。1. 编译Ceres库为什么要这么折腾1.1 Ceres库在Windows下的编译难点Ceres官方虽然提供了Windows支持但在VS2013时代它的构建过程远没有现在这么顺滑。依赖项太多是最大的问题——Eigen、glog、gflags、suitesparseCXSparse、lapack、blas想想就头大。在Linux下一条apt-get命令就能搞定的东西在Windows下全得手动编译而且版本还得对上不然编译报错能让你怀疑人生。我最初试过直接用CMake去configure结果跳出来一堆红字提示找不到这个库那个库。后来才发现关键是要把依赖项一个个解决清楚再回头配置Ceres本体顺序对了才能顺利编译。1.2 各依赖库的角色分工要理解整个编译过程先得知道Ceres依赖的这些库分别是干嘛用的依赖库作用编译必要性Eigen矩阵运算基础库Ceres的核心依赖负责所有线性代数计算必需且版本要够新glog/gflags日志记录和命令行参数解析帮助调试和配置建议编译功能很实用suitesparse稀疏矩阵求解Ceres在处理大规模稀疏问题时依赖它可选但强烈推荐lapack/blas底层线性代数计算库配合suitesparse使用可选稀疏求解时需要请注意Eigen是header-only的不需要编译成lib文件只需要把头文件路径配好就行。这个算是最省心的一个了。其他几个库就得老老实实走编译流程。2. 编译前的准备工作与环境配置2.1 工具清单与版本选择工欲善其事必先利其器在动手编译之前一定要把这些工具准备好。我自己实测通过的组合是Visual Studio 2013 Update 5必须打上补丁不然后面有一堆坑CMake 3.8.2这个版本对VS2013支持比较好太新反而不行Eigen 3.3.7这个版本稳定性很好和VS2013兼容glog 0.3.5 gflags 2.2.1suitesparse 4.4.6这是Windows下最容易出问题的库后面我会细说Ceres Solver 1.13.0这个版本配合上述依赖在VS2013下很稳定太新的版本对编译器要求高注意Ceres版本别乱上1.14以上的那个版本开始对C11/14要求更高了VS2013的C11支持又不太完整用老版本反而省心。2.2 依赖库目录结构规划我习惯在D盘建一个专门的第三方库目录把源码和解压后的文件都放一起方便统一管理。推荐结构如下D:\3rdparty\ ├── eigen3\ ├── glog\ ├── gflags\ ├── suitesparse\ └── ceres-solver\每个目录下再分include、lib、dll这些子目录后面配置CMake的时候会很方便。养成好习惯把编译产物和源码分开也方便以后维护和排查问题。3. 一步步编译各个依赖库3.1 编译glog和gflags先说说gflags。这个最简单直接用CMake打开源码目录配置好生成器为Visual Studio 12 2013 Win64然后Generate用VS2013打开生成的sln文件选择Release x64编译就完事了。注意gflags在Windows下编译时要打开GFLAGS_NAMESPACE这个宏定义不然后面链接会出问题编译器会报找不到google::GetCommandLineFlagInfo之类的错误。glog稍微麻烦一点它依赖gflags。编译时同样用CMake但有一个关键点勾选glog_BUILD_TESTING为OFF不然构建测试程序会消耗大量时间而且有些测试依赖Python脚本VS2013环境下运行容易出岔子。编译成功后你会得到glog.lib、gflags.lib或gflags_static.lib这两个文件名后面配置Ceres时都用得上。3.2 编译suitesparse和依赖的BLAS/LAPACK这个环节是整个编译流程中最容易翻车的地方。suitesparse官方是给Linux设计的Windows下编译那叫一个费劲。我试过两种方案方案一直接用官方源码配合CMake编。需要先把BLAS和LAPACK编好因为suitesparse的PCG和CHOLMOD模块依赖这两个库。LAPACK在Windows下的编译比较麻烦官网提供了预编译的二进制包但我用VS2013去链接时老出问题。方案二用别人已经编译好的版本。GitHub上有好心人放了编译好的suitesparse Windows版本包含所需的各种lib文件和dll。如果你只是想尽快用上Ceres就直接用这个方案省时省力还不容易出错。如果你坚持自己编译我的经验是把LAPACK和BLAS的源码下下来用CMake生成VS2013工程编译Release版本。这里注意LAPACK的CMake工程里会去检测Fortran编译器VS2013默认没装所以需要勾选BUILD_SHARED_LIBS并打开CMAKE_Fortran_COMPILER设置或者干脆用人家编译好的二进制。我自己试下来最稳的还是用别人编译好的版本省出来的时间可以多调几个Bug。3.3 编译Ceres Solver本体所有依赖库备齐之后终于可以编译Ceres本体了。用CMake配置时下面几个关键选项要格外注意CMAKE_PREFIX_PATHD:/3rdparty 这里指向你依赖库存放的根目录 EIGEN_INCLUDE_DIRD:/3rdparty/eigen3 GLOG_INCLUDE_DIRD:/3rdparty/glog/include GLOG_LIBRARYD:/3rdparty/glog/lib/glog.lib GFLAGS_INCLUDE_DIRD:/3rdparty/gflags/include GFLAGS_LIBRARYD:/3rdparty/gflags/lib/gflags.lib LAPACK_LIBRARIESD:/3rdparty/lapack/libs/liblapack.lib BLAS_LIBRARIESD:/3rdparty/lapack/libs/libblas.lib SUITESPARSE_INCLUDE_DIRD:/3rdparty/suitesparse/include SUITESPARSE_LIBRARY_DIRD:/3rdparty/suitesparse/lib别急着Generate先检查一下CMake的报错信息确认所有依赖项都被正确识别特别是那个SuiteSparse相关的选项要显示为YES。我就遇到过由于路径没配对导致CMake静默地关闭了稀疏求解支持的情况结果编译出来的库能力大打折扣。确认无误后点Generate然后用VS2013打开生成的Ceres.sln选择Release x64配置右键解决方案重新生成。第一次编大概需要十到二十分钟主要看机器性能。编完之后在lib\Release文件夹下就能看到ceres.lib和ceres.dll。4. 实操过程中遇到的几个经典坑4.1 “无法打开包括文件: Eigen/Core” 报错这个报错十有八九是Eigen的路径没配置对。Eigen的头文件在unsupported和Eigen两个目录的父目录也就是说你的Include路径应该指向包含Eigen文件夹的那个目录而不是Eigen文件夹本身。我当初就是把EIGEN_INCLUDE_DIR直接指到了Eigen文件夹的上一层结果死活找不到头文件。正确写法是EIGEN_INCLUDE_DIRD:/3rdparty/eigen3这样编译时找的就是D:/3rdparty/eigen3/Eigen/Core刚好能命中目标。4.2 LNK2038运行时库不匹配错误这个错误的典型特征是这样的error LNK2038: mismatch detected for RuntimeLibrary: value MD_DynamicRelease doesnt match value MT_StaticRelease原因很好理解——Ceres编译用的是动态运行时库/MD你的项目用的是静态运行时库/MT或者反过来。解决办法是在编译时统一。我建议都使用动态链接Release下对应/MD也就是CMake里默认的BUILD_SHARED_LIBSON。如果你用的是自己的项目来链接Ceres记得检查你项目的运行库设置——项目属性 → C/C → 代码生成 → 运行库改成多线程DLL(/MD)保证和Ceres库编译时一致。4.3 glog的符号冲突问题有时候编译时会出现google::base相关的符号冲突比如flog和glog同时被包含时就会出这种问题。这是因为glog和gflags都用namespace google存在命名空间污染。最稳妥的办法是在编译glog时打开GLOG_NO_ABBREVIATED_SEVERITIES宏然后在你的项目里也加上这个宏定义。这样glog的级别名称会变成google::GLOG_INFO而不是google::INFO避免和其他库的符号冲突代价是代码里引用日志级别的地方要相应修改。另外一个经验是如果你的项目里还有其他google库尽量把glog和gflags统一版本混用新老版本很容易在链接阶段出现莫名其妙的错误。4.4 动态库运行时找不到DLL编译成功只是第一步运行的时候还会遇到“找不到ceres.dll”这类问题。解决方法很简单在工程项目里设置环境变量或者直接把ceres.dll以及glog.dll、gflags.dll复制到exe所在目录。我喜欢用的是在VS里设置调试环境变量——项目属性 → 调试 → 环境填上PATHD:\3rdparty\ceres-solver\bin;D:\3rdparty\glog\bin;D:\3rdparty\gflags\bin;%PATH%这样调试时就不用频繁拷贝DLL了。5. 快速验证编译是否成功编完之后肯定要跑个测试验证一下。Ceres源码包里自带了一个简单的示例程序在examples文件夹下有helloworld.cc是个最简单的最小二乘问题求解。在你的工程里新建一个控制台程序包含头文件和库配置然后把以下代码贴进去#include ceres/ceres.h #include glog/logging.h using ceres::AutoDiffCostFunction; using ceres::CostFunction; using ceres::Problem; using ceres::Solver; using ceres::Solve; struct CostFunctor { template typename T bool operator()(const T* const x, T* residual) const { residual[0] T(10.0) - x[0]; return true; } }; int main(int argc, char** argv) { google::InitGoogleLogging(argv[0]); double x 0.5; const double initial_x x; Problem problem; CostFunction* cost_function new AutoDiffCostFunctionCostFunctor, 1, 1(new CostFunctor); problem.AddResidualBlock(cost_function, nullptr, x); Solver::Options options; options.minimizer_progress_to_stdout true; Solver::Summary summary; Solve(options, problem, summary); std::cout summary.BriefReport() \n; std::cout x : initial_x - x \n; return 0; }记住在项目属性里配好三样东西包含目录、库目录、附加依赖项。我通常把附加依赖项写成ceres.lib glog.lib gflags.lib如果编译和运行都正常输出结果应该是x从0.5收敛到10。看到这个结果说明你的Ceres库已经可以正常使用了。6. 几个提升效率的小技巧6.1 用属性表保存配置VS2013支持属性表Property Sheet你可以把所有的包含目录、库目录、附加依赖项全部保存到一个.props文件里。这样以后新建项目时只需要在属性管理器中添加这个属性表即可不用每次手动配一遍方便得很。6.2 调试版本的编译如果你需要调试Ceres相关代码建议也编译一个Debug x64版本。注意Debug版本要链接Debug版的依赖库也就是用glogd.lib、gflagsd.lib这些如果混用Release和Debug版本的库会出现一堆运行时错误。如果只需要Release性能Debug版可以先跳过省点硬盘空间和编译时间。6.3 考虑换成vcpkg如果你有精力折腾新版工具链真的建议直接用vcpkg来管理Ceres的依赖和编译vcpkg install ceres:x64-windows一条命令就搞定一切再也不用手动编译glog、gflags、suitesparse那些乱七八糟的依赖了。唯一的问题是vcpkg对VS版本有要求VS2013太老可能无法直接使用最新版本的vcpkg那还是走本文这条手动编译的老路最实在。这次在VS2013 x64环境下编译Ceres库的经历可以说是把我折磨得够呛但也让我把CMake的依赖管理机制和Windows下C库的构建流程好好捋了一遍。踩坑过后我最大的体会是——编译第三方库前一定要先花时间搞清楚依赖关系理清楚先后顺序和版本匹配逻辑再动手执行这样才能少走弯路。希望这篇实战记录能让正在编译Ceres的你顺利一点。本文还有配套的精品资源点击获取
VS2013 x64环境下Ceres Solver编译实战与踩坑指南
简介一份专为VS2013 x64平台编译的Ceres Solver库资源面向需要在Visual Studio 2013中处理非线性最小二乘问题的C开发者适用于计算机视觉、机器人、三维重建等数值优化场景。压缩包大小348.67MB内含2000个文件主体为Ceres及依赖库的源码c、h、cpp、cc和编译生成的obj、lib、dll、exp等库文件同时包含大量用于文档说明的图像与示例数据可在VS2013工程中直接配置引用。已有390人学习下载。该资源省去了手动获取Eigen、glog、gflags等依赖并逐一编译配置的繁琐过程拿到后只需将头文件目录与库文件加入链接器设置即可启用自动微分、损失函数及多种线性求解器帮助开发者快速开展大规模非线性优化开发。 刚开始接触Ceres Solver那会儿我还在用VS2013配x64平台编译这个库前前后后踩了一堆坑折腾了差不多一个周末才把整个流程跑通。最近看到还有人在这上面卡壳我就把自己在VS2013 x64环境下编译Ceres库的过程和心得整理出来希望能帮你少走点弯路。Ceres Solver是谷歌出的一个开源C库专门用来解决非线性最小二乘问题。做SLAM、三维重建、相机标定、传感器融合这些方向的同学应该都不陌生它内部集成了自动求导、数值求导这些工具配合LM算法、Dogleg算法做优化求解非常方便。但是Windows下编译这玩意儿特别是VS2013这种老版本工具链那真是考验人的耐心。1. 编译Ceres库为什么要这么折腾1.1 Ceres库在Windows下的编译难点Ceres官方虽然提供了Windows支持但在VS2013时代它的构建过程远没有现在这么顺滑。依赖项太多是最大的问题——Eigen、glog、gflags、suitesparseCXSparse、lapack、blas想想就头大。在Linux下一条apt-get命令就能搞定的东西在Windows下全得手动编译而且版本还得对上不然编译报错能让你怀疑人生。我最初试过直接用CMake去configure结果跳出来一堆红字提示找不到这个库那个库。后来才发现关键是要把依赖项一个个解决清楚再回头配置Ceres本体顺序对了才能顺利编译。1.2 各依赖库的角色分工要理解整个编译过程先得知道Ceres依赖的这些库分别是干嘛用的依赖库作用编译必要性Eigen矩阵运算基础库Ceres的核心依赖负责所有线性代数计算必需且版本要够新glog/gflags日志记录和命令行参数解析帮助调试和配置建议编译功能很实用suitesparse稀疏矩阵求解Ceres在处理大规模稀疏问题时依赖它可选但强烈推荐lapack/blas底层线性代数计算库配合suitesparse使用可选稀疏求解时需要请注意Eigen是header-only的不需要编译成lib文件只需要把头文件路径配好就行。这个算是最省心的一个了。其他几个库就得老老实实走编译流程。2. 编译前的准备工作与环境配置2.1 工具清单与版本选择工欲善其事必先利其器在动手编译之前一定要把这些工具准备好。我自己实测通过的组合是Visual Studio 2013 Update 5必须打上补丁不然后面有一堆坑CMake 3.8.2这个版本对VS2013支持比较好太新反而不行Eigen 3.3.7这个版本稳定性很好和VS2013兼容glog 0.3.5 gflags 2.2.1suitesparse 4.4.6这是Windows下最容易出问题的库后面我会细说Ceres Solver 1.13.0这个版本配合上述依赖在VS2013下很稳定太新的版本对编译器要求高注意Ceres版本别乱上1.14以上的那个版本开始对C11/14要求更高了VS2013的C11支持又不太完整用老版本反而省心。2.2 依赖库目录结构规划我习惯在D盘建一个专门的第三方库目录把源码和解压后的文件都放一起方便统一管理。推荐结构如下D:\3rdparty\ ├── eigen3\ ├── glog\ ├── gflags\ ├── suitesparse\ └── ceres-solver\每个目录下再分include、lib、dll这些子目录后面配置CMake的时候会很方便。养成好习惯把编译产物和源码分开也方便以后维护和排查问题。3. 一步步编译各个依赖库3.1 编译glog和gflags先说说gflags。这个最简单直接用CMake打开源码目录配置好生成器为Visual Studio 12 2013 Win64然后Generate用VS2013打开生成的sln文件选择Release x64编译就完事了。注意gflags在Windows下编译时要打开GFLAGS_NAMESPACE这个宏定义不然后面链接会出问题编译器会报找不到google::GetCommandLineFlagInfo之类的错误。glog稍微麻烦一点它依赖gflags。编译时同样用CMake但有一个关键点勾选glog_BUILD_TESTING为OFF不然构建测试程序会消耗大量时间而且有些测试依赖Python脚本VS2013环境下运行容易出岔子。编译成功后你会得到glog.lib、gflags.lib或gflags_static.lib这两个文件名后面配置Ceres时都用得上。3.2 编译suitesparse和依赖的BLAS/LAPACK这个环节是整个编译流程中最容易翻车的地方。suitesparse官方是给Linux设计的Windows下编译那叫一个费劲。我试过两种方案方案一直接用官方源码配合CMake编。需要先把BLAS和LAPACK编好因为suitesparse的PCG和CHOLMOD模块依赖这两个库。LAPACK在Windows下的编译比较麻烦官网提供了预编译的二进制包但我用VS2013去链接时老出问题。方案二用别人已经编译好的版本。GitHub上有好心人放了编译好的suitesparse Windows版本包含所需的各种lib文件和dll。如果你只是想尽快用上Ceres就直接用这个方案省时省力还不容易出错。如果你坚持自己编译我的经验是把LAPACK和BLAS的源码下下来用CMake生成VS2013工程编译Release版本。这里注意LAPACK的CMake工程里会去检测Fortran编译器VS2013默认没装所以需要勾选BUILD_SHARED_LIBS并打开CMAKE_Fortran_COMPILER设置或者干脆用人家编译好的二进制。我自己试下来最稳的还是用别人编译好的版本省出来的时间可以多调几个Bug。3.3 编译Ceres Solver本体所有依赖库备齐之后终于可以编译Ceres本体了。用CMake配置时下面几个关键选项要格外注意CMAKE_PREFIX_PATHD:/3rdparty 这里指向你依赖库存放的根目录 EIGEN_INCLUDE_DIRD:/3rdparty/eigen3 GLOG_INCLUDE_DIRD:/3rdparty/glog/include GLOG_LIBRARYD:/3rdparty/glog/lib/glog.lib GFLAGS_INCLUDE_DIRD:/3rdparty/gflags/include GFLAGS_LIBRARYD:/3rdparty/gflags/lib/gflags.lib LAPACK_LIBRARIESD:/3rdparty/lapack/libs/liblapack.lib BLAS_LIBRARIESD:/3rdparty/lapack/libs/libblas.lib SUITESPARSE_INCLUDE_DIRD:/3rdparty/suitesparse/include SUITESPARSE_LIBRARY_DIRD:/3rdparty/suitesparse/lib别急着Generate先检查一下CMake的报错信息确认所有依赖项都被正确识别特别是那个SuiteSparse相关的选项要显示为YES。我就遇到过由于路径没配对导致CMake静默地关闭了稀疏求解支持的情况结果编译出来的库能力大打折扣。确认无误后点Generate然后用VS2013打开生成的Ceres.sln选择Release x64配置右键解决方案重新生成。第一次编大概需要十到二十分钟主要看机器性能。编完之后在lib\Release文件夹下就能看到ceres.lib和ceres.dll。4. 实操过程中遇到的几个经典坑4.1 “无法打开包括文件: Eigen/Core” 报错这个报错十有八九是Eigen的路径没配置对。Eigen的头文件在unsupported和Eigen两个目录的父目录也就是说你的Include路径应该指向包含Eigen文件夹的那个目录而不是Eigen文件夹本身。我当初就是把EIGEN_INCLUDE_DIR直接指到了Eigen文件夹的上一层结果死活找不到头文件。正确写法是EIGEN_INCLUDE_DIRD:/3rdparty/eigen3这样编译时找的就是D:/3rdparty/eigen3/Eigen/Core刚好能命中目标。4.2 LNK2038运行时库不匹配错误这个错误的典型特征是这样的error LNK2038: mismatch detected for RuntimeLibrary: value MD_DynamicRelease doesnt match value MT_StaticRelease原因很好理解——Ceres编译用的是动态运行时库/MD你的项目用的是静态运行时库/MT或者反过来。解决办法是在编译时统一。我建议都使用动态链接Release下对应/MD也就是CMake里默认的BUILD_SHARED_LIBSON。如果你用的是自己的项目来链接Ceres记得检查你项目的运行库设置——项目属性 → C/C → 代码生成 → 运行库改成多线程DLL(/MD)保证和Ceres库编译时一致。4.3 glog的符号冲突问题有时候编译时会出现google::base相关的符号冲突比如flog和glog同时被包含时就会出这种问题。这是因为glog和gflags都用namespace google存在命名空间污染。最稳妥的办法是在编译glog时打开GLOG_NO_ABBREVIATED_SEVERITIES宏然后在你的项目里也加上这个宏定义。这样glog的级别名称会变成google::GLOG_INFO而不是google::INFO避免和其他库的符号冲突代价是代码里引用日志级别的地方要相应修改。另外一个经验是如果你的项目里还有其他google库尽量把glog和gflags统一版本混用新老版本很容易在链接阶段出现莫名其妙的错误。4.4 动态库运行时找不到DLL编译成功只是第一步运行的时候还会遇到“找不到ceres.dll”这类问题。解决方法很简单在工程项目里设置环境变量或者直接把ceres.dll以及glog.dll、gflags.dll复制到exe所在目录。我喜欢用的是在VS里设置调试环境变量——项目属性 → 调试 → 环境填上PATHD:\3rdparty\ceres-solver\bin;D:\3rdparty\glog\bin;D:\3rdparty\gflags\bin;%PATH%这样调试时就不用频繁拷贝DLL了。5. 快速验证编译是否成功编完之后肯定要跑个测试验证一下。Ceres源码包里自带了一个简单的示例程序在examples文件夹下有helloworld.cc是个最简单的最小二乘问题求解。在你的工程里新建一个控制台程序包含头文件和库配置然后把以下代码贴进去#include ceres/ceres.h #include glog/logging.h using ceres::AutoDiffCostFunction; using ceres::CostFunction; using ceres::Problem; using ceres::Solver; using ceres::Solve; struct CostFunctor { template typename T bool operator()(const T* const x, T* residual) const { residual[0] T(10.0) - x[0]; return true; } }; int main(int argc, char** argv) { google::InitGoogleLogging(argv[0]); double x 0.5; const double initial_x x; Problem problem; CostFunction* cost_function new AutoDiffCostFunctionCostFunctor, 1, 1(new CostFunctor); problem.AddResidualBlock(cost_function, nullptr, x); Solver::Options options; options.minimizer_progress_to_stdout true; Solver::Summary summary; Solve(options, problem, summary); std::cout summary.BriefReport() \n; std::cout x : initial_x - x \n; return 0; }记住在项目属性里配好三样东西包含目录、库目录、附加依赖项。我通常把附加依赖项写成ceres.lib glog.lib gflags.lib如果编译和运行都正常输出结果应该是x从0.5收敛到10。看到这个结果说明你的Ceres库已经可以正常使用了。6. 几个提升效率的小技巧6.1 用属性表保存配置VS2013支持属性表Property Sheet你可以把所有的包含目录、库目录、附加依赖项全部保存到一个.props文件里。这样以后新建项目时只需要在属性管理器中添加这个属性表即可不用每次手动配一遍方便得很。6.2 调试版本的编译如果你需要调试Ceres相关代码建议也编译一个Debug x64版本。注意Debug版本要链接Debug版的依赖库也就是用glogd.lib、gflagsd.lib这些如果混用Release和Debug版本的库会出现一堆运行时错误。如果只需要Release性能Debug版可以先跳过省点硬盘空间和编译时间。6.3 考虑换成vcpkg如果你有精力折腾新版工具链真的建议直接用vcpkg来管理Ceres的依赖和编译vcpkg install ceres:x64-windows一条命令就搞定一切再也不用手动编译glog、gflags、suitesparse那些乱七八糟的依赖了。唯一的问题是vcpkg对VS版本有要求VS2013太老可能无法直接使用最新版本的vcpkg那还是走本文这条手动编译的老路最实在。这次在VS2013 x64环境下编译Ceres库的经历可以说是把我折磨得够呛但也让我把CMake的依赖管理机制和Windows下C库的构建流程好好捋了一遍。踩坑过后我最大的体会是——编译第三方库前一定要先花时间搞清楚依赖关系理清楚先后顺序和版本匹配逻辑再动手执行这样才能少走弯路。希望这篇实战记录能让正在编译Ceres的你顺利一点。本文还有配套的精品资源点击获取
