自动驾驶计算机视觉【免费下载链接】SensorsCalibrationOpenCalib: A Multi-sensor Calibration Toolbox for Autonomous Driving项目地址https://gitcode.com/gh_mirrors/se/SensorsCalibration点击查看免费下载gflagsGoogle Commandline Flags是 Google 开源的一套 C 命令行参数解析库它以极简的DEFINE_xxx/FLAGS_xxx宏体系让程序参数的定义、解析、帮助与校验变得异常顺手。本文以 SensorsCalibration 仓库中内置的 gflags 版本说明文档 为核心骨架梳理 gflags 从 1.0 到 2.2.2 的十余年演进脉络并结合仓库内源码与构建脚本讲清命名空间、构建系统、命令行 API 等关键机制以及它作为第三方依赖如何被集成进 lidar2car 标定模块。读完本文你将能准确理解 gflags 版本之间的兼容性边界并掌握在自研 C 工程中引入、配置与使用 gflags 的完整姿势。gflags 是什么为何出现在多传感器标定工具箱中gflags 的核心价值在于把「命令行参数」从手工argc/argv解析中解放出来程序员只需用宏声明一个全局变量如DEFINE_int32(port, 0, What port to listen on)gflags 就会自动完成命令行解析、--help帮助生成、默认值管理乃至合法性校验。这个库本身只有gflags.cc、gflags_reporting.cc、gflags_completions.cc等少量源文件见 gflags 源码目录却支撑起了 Ceres Solver、glog 等众多知名 C 项目的参数系统。在 SensorsCalibration 仓库中gflags 被放置在SensorX2car/lidar2car/3rdparty/gflags/下作为 lidar2car激光雷达→车体外参标定模块的第三方依赖随源码一起分发。其集成方式非常典型3rdparty/CMakeLists.txt 中通过add_subdirectory(gflags)将 gflags 与 ceres、g2o、glog 一同纳入构建并把include与lib目录导出为3RDPATRYS_INCLUDE_DIRS/3RDPATRYS_LINK_DIRS编译好的公开头文件被集中安装到 3rdparty/include/gflags/gflags.h、gflags_declare.h、gflags_gflags.h、gflags_completions.h上层的 Ceres Solver 依赖 gflags 提供命令行参数能力在 ceres/CMakeLists.txt 中通过find_package(gflags 2.2.0 CONFIG ...)探测 gflags并把gflags追加为公开依赖。也就是说对标定工具箱而言 gflags 是「基础设施」级别的依赖标定主程序未必直接调用它但整个 Ceres/glog 生态的稳定性都建立在这个命令行库之上。版本编年史README 记录的核心演进gflags README 本质是一份从 2008 年 1.0 到 2018 年 2.2.2 的发布记录其中每一个版本节点都对应着具体的技术决策。下面按时代分段还原这份演进史。2.x 时代构建体系与命名空间的现代化2.2.22018-11-11维护版显著改善 Bazel 用户的体验config.h不再泄漏到全局 include 路径修复近期 MinGW 版本的构建问题消除一批静态代码分析器与编译器告警CMake 配置导出的构建目标新增gflags::包名前缀遵循当时未成文的 CMake 惯例同时保留不带前缀的目标名避免已有依赖项目因导入目标名变化而被迫修改。2.2.12017-07-11维护版主要修复 Windows 构建问题与静态分析器误报。2.2.02016-11-25功能版除 CMake 外正式支持以外部依赖形式接入 Bazel 与 pkg-config新增一项小特性命令行参数中的短横线dash会被隐式转换为下划线underscore。即习惯用--foo-bar分隔单词的用户可以照常书写而标志变量名仍必须使用下划线修复 valgrind 报告的内存泄漏修复 MS Visual Studio 2015 下的编译错误。2.1.22015-03-24完成命名空间变更的收尾工作恢复与 2.0 版本的二进制 ABI 兼容默认仍保留已废弃的google命名空间作为主命名空间同时把符号导入新的gflags命名空间这一行为可通过 CMake 变量GFLAGS_NAMESPACE覆盖移除补丁版的FindThreads.cmake与CheckTypeSize.cmake模块重新启用 C 语言支持尽管 gflags 本身是纯 C项目托管从 Google Code 完全迁移至 GitHub。2.1.12014-03-30修复gflags_declare.h配置中的若干 bug构建配置新增独立的GFLAGS_INCLUDE_DIRCMake 变量将GFLAGS_NAMESPACE设为google时不再同时改变公开头文件的 include 路径——这让 gflags 能与 glog 等仍使用旧google命名空间的项目共存但统一以gflags/gflags.h方式包含。2.12014-03-20构建系统从 autotools 全面切换为CMake并通过 CPack 提供打包支持所有 C 符号的默认命名空间由google改为gflags可通过GFLAGS_NAMESPACE变量配置该版本可在 Ubuntu 12.04、Windows 7VS2008/2010、Cygwin、MinGW、Mac OS XXcode 5.1上无警告编译并通过单元测试。2.02012-01-25google-gflags项目正式更名为gflags维护者由 csilvers 移交给 Andreas Schuh主版本号升至 2 以反映社区所有权的变更功能上与 1.7 无差异代码仍保留在google命名空间后续版本才逐步迁移并保留/usr/local/include/google/作为/usr/local/include/gflags/的同义目录。1.x 时代跨平台与易用性的积累1.72011-12-20CommandLineFlagInfo开始导出标志所在的内存地址flag_ptr修复超长--help字符串相关 bug。1.62011-07-29新增版本信息支持使--version真正有用ReparseCommandlineFlags返回值由int改为void原int返回值本就无意义属于需要版本号提升的 ABI 变更。1.52011-01-24改进--help的报告输出新增内存清理函数以帮助在 valgrind 下运行 gflags 程序修复DEFINE_bool等宏在命名空间内使用的可靠性。1.42010-10-11文档改进与库体积缩减。1.32010-01-04gflags 可在MSVC下编译并通过全部测试Python 版拆分为独立的 python-gflags 库。1.22009-09-10支持MinGW以及 cygwin编译全部测试通过。1.12009-04-15更换 .deb/.rpm 打包系统支持 x86_64 包统一libgflags.so库名此前 deb 包曾错误地生成libgoogle-gflags.so。1.02008-10-01头文件由/usr/include/google迁移到/usr/include/gflags保留向后兼容转发头官方推荐改写为#include gflags/gflags.h默认命名空间仍为google可通过 configure 参数修改新增 bash 命令行补全支持。命名空间演进google 到 gflags 的兼容策略命名空间是 gflags 演进史中最核心的一条线索也是集成时最容易踩坑的地方。仓库源码为我们提供了完整的证据链模板文件 src/gflags_declare.h.in 中通过#define GFLAGS_NAMESPACE GFLAGS_NAMESPACE在构建期注入命名空间名模板文件 src/gflags_ns.h.in 展示了「替代/废弃命名空间」的导入机制用using GFLAGS_NAMESPACE::int32; using GFLAGS_NAMESPACE::RegisterFlagValidator; ...把主命名空间符号逐一导入到兼容命名空间src/gflags.h.in 末尾的INCLUDE_GFLAGS_NS_H占位符在构建时展开为对应命名空间的导入头gflags 的 CMakeLists.txt 中GFLAGS_NAMESPACE的默认值为google;gflags即默认同时生成 google 与 gflags 两个命名空间主命名空间取第一个google其余作为兼容命名空间导入并要求命名空间标识符符合^[a-zA-Z][a-zA-Z0-9_]*$规则。而当前仓库实际构建时选择了把google固定为主命名空间编译产物 3rdparty/include/gflags/gflags_declare.h 中写死#define GFLAGS_NAMESPACE google同时 gflags_gflags.h 负责把符号再导入gflags命名空间。这与 README 中 2.1.1/2.1.2 描述的兼容策略完全一致——为了与仍使用google命名空间的 glog 等旧项目共存同时让新代码可以通过gflags命名空间访问。实际编码中推荐写法是使用GFLAGS_NAMESPACE::宏而非硬编码命名空间名例如 Ceres 自带测试 gmock_main.cc 中调用GFLAGS_NAMESPACE::ParseCommandLineFlags(argc, argv, true)。这样无论库以哪种命名空间编译你的代码都能正确解析。构建与依赖管理从 autotools 到 CMake、Bazel、pkg-configREADME 记录了构建体系的三次跃迁1.x 时代使用 autotools 与 configure 脚本如 1.0 用./configure --help查看配置选项、1.1 切换打包系统2.1 起迁移到 CMake CPack2.2.0 又补齐 Bazel 与 pkg-config 支持2.2.2 再引入gflags::目标前缀。仓库中的 gflags CMakeLists.txt 是这一体系的具体落地cmake_minimum_required (VERSION 3.0.2 FATAL_ERROR)PACKAGE_VERSION为2.2.2见 CMakeLists.txt 第 93-101 行通过gflags_define宏定义了一批可配置构建选项例如BUILD_SHARED_LIBS、BUILD_STATIC_LIBS、BUILD_gflags_LIB多线程库、BUILD_gflags_nothreads_LIB单线程库、BUILD_PACKAGINGCPack、BUILD_TESTINGCTest、INSTALL_HEADERS等见 CMakeLists.txt 第 169-181 行支持GFLAGS_IS_SUBPROJECT子项目模式当 gflags 作为add_subdirectory被引入本仓库正是如此默认只构建静态单线程库gflags_nothreads_static不安装文件gflags::gflags目标作为其 ALIAS只有当 gflags 作为顶层项目时才写入 CMake 缓存供 GUI 编辑见 CMakeLists.txt 第 131-140 行GFLAGS_INTTYPES_FORMAT自动探测整数类型格式C99/BSD/VC7分别对应uint32_t、u_int32_t、__int32Windows 下还会额外检查HAVE_STDINT_H/HAVE_INTTYPES_H见 CMakeLists.txt 第 268-294 行。作为对比gflags 自带的 INSTALL.md 给出了四种官方安装路径均可用于脱离本仓库的独立开发Debian/Ubuntu 二进制包sudo apt-get install libgflags-devmacOS Homebrewbrew install gflagsvcpkggit clone https://github.com/Microsoft/vcpkg.git后依次执行./bootstrap-vcpkg.sh、./vcpkg integrate install、vcpkg install gflagsBazel 外部依赖在WORKSPACE中声明git_repository(name com_github_gflags_gflags, ...)随后在cc_binary/cc_library的deps中加入com_github_gflags_gflags//:gflags源码 CMake 构建gflags 官方主推见 INSTALL.md$ tar xzf gflags-$version-source.tar.gz $ cd gflags-$version $ mkdir build cd build $ ccmake .. # - Press c to configure, e to ignore warnings # - Set CMAKE_INSTALL_PREFIX and other CMake variables # - Press g to generate Makefiles $ make $ make test # optional $ make install # optionalINSTALL.md 还汇总了 gflags 特有的 CMake 配置选项表这里完整保留并补充说明CMake 选项说明CMAKE_INSTALL_PREFIX安装目录Unix 下如/usr/localWindows 下如C:\Program Files\gflagsBUILD_SHARED_LIBS请求构建动态链接库BUILD_STATIC_LIBS请求构建静态链接库BUILD_SHARED_LIBS为 OFF 时默认隐含开启BUILD_PACKAGING启用 CPack 二进制包生成BUILD_TESTING构建供 CTest 执行的测试BUILD_NC_TESTS请求加入负编译测试需要 PythonBUILD_CONFIG_TESTS请求加入包配置测试需要 PythonBUILD_gflags_LIBS构建多线程版 gflags 库找到线程库时BUILD_gflags_nothreads_LIBS构建单线程版 gflags 库GFLAGS_NAMESPACE库使用的 C 命名空间公开头文件安装在其同名子目录下为兼容旧的 Google Commandline Flags 可设为google默认gflagsGFLAGS_INTTYPES_FORMAT内置整数类型的格式标识C99/BSD/VC7GFLAGS_INCLUDE_DIR头文件安装目录相对CMAKE_INSTALL_PREFIX的名称LIBRARY_INSTALL_DIR库文件安装目录相对CMAKE_INSTALL_PREFIXINSTALL_HEADERS是否安装公开头文件命令行解析 API 与 DEFINE/DECLARE 宏体系虽然 README 主要记录版本演进但仓库源码完整呈现了 gflags 的使用方式二者结合能让读者真正上手。官方推荐的最小用法在 src/gflags.h.in 头部注释中给出#include foo.h // foo.h 中有 DECLARE_int32(start); DEFINE_int32(end, 1000, The last record to read); DEFINE_string(filename, my_file.txt, The file to read); // 校验器文件不存在则校验失败 static bool dummy RegisterFlagValidator(FLAGS_filename, ValidateIsFile); DECLARE_bool(verbose); // 其他文件里已有 DEFINE_bool(verbose, ...) void MyFunc() { if (FLAGS_verbose) printf(Records %d-%d\n, FLAGS_start, FLAGS_end); }对应的命令行调用为./foo --noverbose --start5 --end100。注意布尔标志的--no前缀约定--noverbose等价于FLAGS_verbose false。围绕这套宏源码中有几个值得注意的实现细节DEFINE 与 DECLARE 分离DEFINE_xxx定义标志并注册见 gflags.h.in 中的 DEFINE_VARIABLE 宏内部通过FlagRegisterer把标志名、帮助文本、文件名和当前/默认值存储注册进全局表DECLARE_xxx仅声明FLAGS_xxx外部变量见 gflags_declare.h.in。DEFINE 宏还把变量放入fLB/fLI/fLS等内部命名空间以强制类型一致性——防止有人DEFINE_bool后又在别处DECLARE_int32。FLAGS_noname防冲突设计每个标志会额外生成一个FLAGS_noname哑变量若有人定义了名为noname的标志就会在链接期报错因为--foo与--nofoo本就会作用于同一个布尔标志容易引起混淆见 gflags.h.in 第 410-416 行。字符串标志的特殊处理DEFINE_string不能像 POD 一样在静态初始化期构造因此用placement new在静态缓冲区构造clstring并注册StringFlagDestructor在退出时显式析构见 gflags.h.in 第 561-618 行。gflags 自带的内部标志src/gflags.cc 定义了--flagfile从文件加载标志、--fromenv/--tryfromenv从环境变量导入、--undefok允许未定义标志等内置标志。入口函数ParseCommandLineFlags(int* argc, char*** argv, bool remove_flags)负责解析并调整 argvSetUsageMessage()/SetVersionString()分别设置--help与--version输出实现位于 src/gflags.cc。仓库测试 test/gflags_unittest.cc 是这套 API 最生动的用法示范从DEFINE_string(test_tmpdir, , ...)、DEFINE_bool(test_bool, false, ...)到DEFINE_validator(always_fail, AlwaysFail)、RegisterFlagValidator、GetAllFlags等都有覆盖可作为快速上手的参考用例。README 中还提到 1.5 之后宏在命名空间内更可靠、1.6 起--version可用、1.7 起CommandLineFlagInfo携带flag_ptr内存地址——这些都可以在 gflags.h.in 的 CommandLineFlagInfo 结构体 中找到对应字段。在 SensorsCalibration 中集成 gflags 的注意事项综合 README 的版本信息与仓库实际布局在当前工程中使用/升级 gflags 时应注意以下几点命名空间以构建产物为准本仓库 3rdparty/include 下编译好的头文件固定为google命名空间GFLAGS_NAMESPACE google业务代码请统一使用GFLAGS_NAMESPACE::或直接依赖 glog/Ceres 的封装避免硬编码gflags::造成链接失败依赖目标建议使用gflags::gflags2.2.2 之后 CMake 导出目标带gflags::前缀无前缀目标仍保留当 gflags 作为子项目引入时gflags::gflags是官方推荐的链接目标短横线与下划线等价2.2.0命令行可写--flag-file代码中访问FLAGS_flag_file二者等价子项目模式默认精简作为add_subdirectory引入时默认仅编译静态单线程库、不安装本仓库 3rdparty/CMakeLists.txt 正是此模式与 glog 的版本配套Ceres 的 CMake 在探测到 gflags 时会假定 glog 以 gflags 支持方式构建并把 gflags 变为 Ceres 的公开依赖见 ceres/CMakeLists.txt 第 459-470 行因此三者版本最好同步升级。小结从 1.0 的头文件路径迁移到 2.1 的 CMake 化与命名空间切换再到 2.2.x 的 Bazel/pkg-config 支持与目标前缀规范gflags 的每一次版本跃迁都遵循着「向后兼容优先、渐进迁移」的原则。这份 README 看似只是发布记录实则是理解整个 C 命令行解析生态与 Ceres/glog 依赖关系的钥匙。结合 SensorsCalibration 仓库中编译好的头文件、构建脚本与测试用例开发者可以快速判断自己的工程应选择哪个 gflags 版本、使用哪个命名空间、如何正确链接从而在多传感器标定这类大型 C 工程中少踩无数兼容性坑。赞分享自动驾驶计算机视觉【免费下载链接】SensorsCalibrationOpenCalib: A Multi-sensor Calibration Toolbox for Autonomous Driving项目地址https://gitcode.com/gh_mirrors/se/SensorsCalibration点击查看免费下载相关推荐Blender 内置 gflags 命令行参数库从 README 版本演进到源码级解析Blender 内置 gflags 命令行参数库从 README 版本演进到源码级解析 gflagsGoogle Flags是 Google 开源的 C图形学3D渲染桌面应用音视频SensorsCalibration 中的 Ceres Solver从 1.0 到 2.0 的版本演进、API 变迁与多传感器标定实践SensorsCalibration 中的 Ceres Solver从 1.0 到 2.0 的版本演进、API 变迁与多传感器标定实践 Ceres Solve自动驾驶计算机视觉goo-engine 中的 gflags从 Google 命令行参数库到 Blender 渲染管线日志系统的集成实践goo engine 中的 gflags从 Google 命令行参数库到 Blender 渲染管线日志系统的集成实践 gflagsGoogle Flags图形学3D渲染上一篇抖音无水印下载终极解决方案技术架构解析与实战应用指南下一篇告别水印烦恼抖音视频批量下载工具全面解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考