首页 / 资讯中心 / 文章详情

为 OpenMVG 贡献代码:分支模型、单元测试与文档规范的完整指南

为 OpenMVG 贡献代码:分支模型、单元测试与文档规范的完整指南 ★ FEATURED ARTICLE
计算机视觉科研【免费下载链接】openMVGopen Multiple View Geometry library. Basis for 3D computer vision and Structure from Motion.项目地址https://gitcode.com/gh_mirrors/op/openMVG点击查看免费下载本文以 OpenMVG 仓库根目录下的 CONTRIBUTING.md 为骨架系统讲解向这个 Open Multiple View Geometry C 库提交贡献的完整路径从基于develop分支的开发流程、master与develop的分支职责划分到新增代码必须配套的单元测试基于 CppUnitLite 的断言宏体系与UNIT_TESTCMake 宏、Doxygen/Sphinx 文档要求以及最终向develop发起 Pull Request 并接受 CI 检查的收尾环节。读完本文你将能独立完成一个 OpenMVG 补丁从编写、测试、文档化到提交合入的全流程。贡献入口Issue 与 Pull RequestCONTRIBUTING.md 首先明确了贡献的欢迎范围bug 报告、bug 修复、新功能feature以及各类反馈提交渠道是 GitHub 上的issues form 和 pull requests。从仓库现状看OpenMVG 的协作基础设施已经围绕 GitHub 完整搭建Issue 与 PR 的自动化检查集中在 .github/workflows 目录下包含compile_and_run_test.yml、compile_and_run_test_external_deps.yml、codeql.yml三个工作流另有.coveralls.yml与.lgtm.yml表明项目历史上还接入了覆盖率统计与 LGTM 静态分析详见下文 CI 一节。贡献的第一步是先描述清楚问题或提案通过 Issue再动手改代码通过 PR这能避免重复劳动并让维护者提前介入设计讨论。分支模型master 存发布版develop 存下个版本候选CONTRIBUTING.md 给出的第一条硬性要求是从develop分支开始你的开发。仓库对两个核心分支的职责划分如下分支职责master存放当前发布版本current release保持稳定只接受经过验证的合入develop存放下一个 release candidate 的 WIPWork In Progress代码所有新功能都应提交到这里这一模型在 CI 配置中得到了直接印证。.github/workflows/compile_and_run_test.yml 第 5-7 行明确将push与pull_request的触发分支限定为main, master, develop, develop_keypoint_orientation_sfm其中develop是提交补丁的主目标develop_keypoint_orientation_sfm则是长期存在的特性分支——这进一步说明项目对特性在独立分支上发育、稳定后合入 develop的实践。实操要点克隆仓库后先切换到develop并保持同步git clone https://gitcode.com/gh_mirrors/op/openMVG git checkout develop git pull origin develop为你的改动创建专属特性分支推荐命名如feature/xxx或fix/xxx完成开发、测试、文档后将 PR 的目标分支设为develop而不是master——直接向master提交新功能不符合项目流程。单元测试新增代码的强制性配套CONTRIBUTING.md 的第二条要求是为所有新增代码添加单元测试。文档给出的理由非常明确单元测试既能校验代码实现的正确性又能示范 API 的用法同时为未来的维护提供保障——后续任何重构或回归都能被测试第一时间发现。测试宏体系testing.hOpenMVG 的测试基础设施位于 src/testing/testing.h它基于第三方框架CppUnitLite位于 src/third_party/CppUnitLite并针对数值计算场景封装了一套断言宏宏用途底层实现EXPECT_MATRIX_NEAR(a, b, tolerance)断言两个矩阵逐元素近似相等先CHECK_EQUAL校验行列数再用DOUBLES_EQUAL逐元素比较EXPECT_MATRIX_NEAR_ZERO(a, tolerance)断言矩阵各元素接近 0逐元素DOUBLES_EQUAL(0.0, ...)EXPECT_MATRIX_EQ(a, b)断言两个矩阵精确相等逐元素CHECK_EQUALEXPECT_MATRIX_PROP(a, b, tolerance)断言两矩阵方向近似一致通过CosinusBetweenMatrices计算夹角余弦校验sin(angle) tolerance适用于旋转矩阵、本质矩阵等方向敏感量的比较EXPECT_NEAR(expected, actual, threshold)标量近似比较DOUBLES_EQUALEXPECT_TRUE(condition)/EXPECT_FALSE(condition)布尔断言CHECKEXPECT_EQ(a, b)标量精确相等CHECK_EQUAL这些宏与 Eigen 矩阵类型eigen_alias_definition.hpp深度绑定是编写几何、相机、多视几何算法测试时的标准工具。测试的组织与注册UNIT_TEST CMake 宏单测的构建注册由 src/CMakeLists.txt 第 235-251 行的UNIT_TEST(NAMESPACE NAME EXTRA_LIBS)宏完成其行为如下在OpenMVG_BUILD_TESTS开启时为每个xxx_test.cpp生成可执行文件${NAMESPACE}_test_${NAME}自动链接CppUnitLite测试运行库通过add_test将可执行文件注册到 CTest测试名形如openMVG_test_Camera_Pinhole通过-DTHIS_SOURCE_DIR${CMAKE_CURRENT_SOURCE_DIR}向测试注入源码目录路径方便测试读取image_test等目录下的样例数据。各模块的 CMakeLists 只需一行即可挂载测试。以相机模块 src/openMVG/cameras/CMakeLists.txt 为例UNIT_TEST(openMVG Camera_Pinhole openMVG_camera) UNIT_TEST(openMVG Camera_Pinhole_Radial openMVG_camera) UNIT_TEST(openMVG Camera_Pinhole_Brown openMVG_camera) UNIT_TEST(openMVG Camera_Pinhole_Fisheye openMVG_camera) UNIT_TEST(openMVG Camera_Spherical openMVG_camera) UNIT_TEST(openMVG Camera_Subset_Parametrization openMVG_camera) UNIT_TEST(openMVG Camera_IO openMVG_camera_test;${STLPLUS_LIBRARY})而src/testing/CMakeLists.txt则定义了openMVG_testing这个 INTERFACE 库用于给测试代码提供头文件路径与openMVG_numeric依赖。一个真实测试文件的解剖以 src/openMVG/cameras/Camera_Pinhole_test.cpp 为例OpenMVG 单测文件的标准骨架是#include openMVG/cameras/Camera_Pinhole.hpp using namespace openMVG; using namespace openMVG::cameras; #include testing/testing.h // 断言宏 #include openMVG/cameras/Camera_Unit_Test.inl // 共享测试用例 TEST(Cameras_Radial, disto_undisto_K1) { const Pinhole_Intrinsic cam(1000, 1000, 1000, 500, 500); Test_camera(cam); // 复用 .inl 中定义的通用校验例程 } /* ************************************************************************* */ int main() { TestResult tr; return TestRegistry::runAllTests(tr);} /* ************************************************************************* */值得注意的实践细节测试用例可以复用*.inl中共享的校验例程如Camera_Unit_Test.inl中的Test_camera避免重复代码每个测试文件自带main()通过TestRegistry::runAllTests(tr)运行本文件内全部TEST(...)用例——这也是 CppUnitLite 的典型用法这种一文件一可执行文件的结构让每个模块的测试可以独立运行、独立排查。如何构建与运行全部测试项目的 CI见 .github/workflows/compile_and_run_test.yml给出了标准构建命令本地复现只需mkdir ./build cd ./build cmake ../src \ -DOpenMVG_BUILD_TESTSON \ -DOpenMVG_BUILD_EXAMPLESON \ -DOpenMVG_BUILD_SOFTWARESON \ -DSCHUR_SPECIALIZATIONSOFF cmake --build . -j$(getconf _NPROCESSORS_ONLN) ctest -j$(getconf _NPROCESSORS_ONLN) --build-config Release说明OpenMVG_BUILD_TESTSON是编译单测的开关默认关闭它会同时触发 src/CMakeLists.txt 中的enable_testing()ctest直接驱动全部注册的单元测试CTEST_OUTPUT_ON_FAILURE1环境变量可让失败时直接打印详细输出若只想运行单个测试可在 build 目录中直接执行对应可执行文件例如./openMVG_test_Camera_Pinhole。文档Doxygen 注释 Sphinx 扩展CONTRIBUTING.md 的第三条要求是为代码编写文档具体规范是请使用 Doxygen 文档。并进一步建议你也可以考虑扩展现有的 Sphinx 文档见./docs/sphinx。DoxygenAPI 注释的标准OpenMVG 的公开头文件普遍采用 Doxygen 风格的注释块/** ... */配合param、return、brief等标签。Doxygen 的构建配置位于 docs/doxygen/Doxyfile.in它作为模板在 CMake 配置阶段生成实际的Doxyfile。给新 API 添加注释时请保持与相邻头文件一致的注释风格确保file、brief、ingroup等元信息完整这样才能生成结构良好的类/函数索引。Sphinx用户级文档的扩展仓库的 Sphinx 文档树以 docs/sphinx 为根源文件全部是 reStructuredText.rst格式构建配置为 docs/sphinx/rst/conf.py其中启用的扩展包括sphinx.ext.autodoc从源码 docstring 自动抽取文档sphinx.ext.viewcode在文档中嵌入源码查看链接sphinx.ext.todo管理 TODO 标记sphinx.ext.mathjax用 MathJax 渲染公式对多视几何文档至关重要sphinx.ext.ifconfig条件内容控制。文档内容按主题组织在 docs/sphinx/rst/openMVG核心库模块、docs/sphinx/rst/openMVG_Samples示例程序、docs/sphinx/rst/softwareSfM 工具链等目录下此外还有 FAQ、dependencies、third_party、bibliography 等栏目主目录树入口是index.rst。如果你的改动引入新的命令行工具、新的软件流程或新的使用模式建议在对应的.rst章节中补充说明并确保被index.rst的 toctree 收录。推送变更并提交 PR向 develop 发起CONTRIBUTING.md 的第四条要求是推送你的变更并向develop发起 PR。同时明确要求检查持续集成工具的状态当时列举的是编译Compilationtravis、appveyor代码质量与风格Code quality and stylecodacity。需要说明的是CONTRIBUTING.md 中提到的这些工具是文档撰写时期的 CI 栈从当前仓库的 .github/workflows 目录看项目实际已迁移到GitHub Actions承担同类职责的工作流包括工作流职责compile_and_run_test.yml在ubuntu-latest、macOS-latest、windows-latest三平台矩阵上完成 CMake 配置、编译与ctest单元测试并在push/pull_request到master/develop等分支时触发compile_and_run_test_external_deps.yml使用外部系统依赖而非仓库内置的 third_party再跑一遍构建与测试验证对外部环境兼容性codeql.yml基于 CodeQL 的代码质量与安全静态分析对应文档中代码质量与风格的检查诉求PR 提交前的自检清单对应 CONTRIBUTING.md 的完整要求当前分支基于develop创建未直接改master所有新增代码都有对应的单元测试且本地ctest全部通过新增公开 API 有完整的 Doxygen 注释必要时补充了 Sphinx.rst文档已推送分支并发起目标为develop的 Pull RequestPR 上三平台编译测试GitHub Actions与静态分析CodeQL均呈绿色通过状态。参考与延伸CONTRIBUTING.md 在结尾建议读者通过开源社区通用指南opensource.guide进一步了解开源协作文化——该站是 GitHub 官方维护的开源入门读物涵盖许可证、行为准则、社区运营等通用话题与本仓库的具体开发流程无直接绑定关系。就 OpenMVG 而言更贴近实操的补充资料还包括 BUILD.md构建全流程、docs/sphinx/rst/index.rst库与软件的使用手册以及 AUTHORS贡献者署名约定。从仓库源码结构看CONTRIBUTING.md 所述规范已经完整落地为可执行的工程设施分支策略有 CI workflow 的触发分支背书测试要求有 testing.h 宏体系与UNIT_TESTCMake 宏支撑文档要求有 Doxyfile.in 与 Sphinx 配置 承接。遵循本文梳理的流程你的第一个 OpenMVG 补丁就能以符合社区规范的方式进入develop为下一个 release candidate 贡献力量。赞分享计算机视觉科研【免费下载链接】openMVGopen Multiple View Geometry library. Basis for 3D computer vision and Structure from Motion.项目地址https://gitcode.com/gh_mirrors/op/openMVG点击查看免费下载相关推荐jsoneditor 贡献指南分支策略、StandardJS 代码规范与单元测试工作流jsoneditor 贡献指南分支策略、StandardJS 代码规范与单元测试工作流 导读 本文基于 jsoneditor 仓库根目录的 CONTRIBUT前端UI组件COLMAP 贡献指南代码风格、注释规范与单元测试的完整参与标准COLMAP 贡献指南代码风格、注释规范与单元测试的完整参与标准 导读 本文以 COLMAP 官方贡献文档 doc/contribution.rst http计算机视觉图形学图像处理seaborn开源贡献指南测试、代码规范与文档构建完整流程seaborn开源贡献指南测试、代码规范与文档构建完整流程 seaborn 是基于 matplotlib 的 Python 统计 数据可视化 库提供绘制美观数据可视化数据分析上一篇Kirby CMS Starterkit错误调试技巧快速定位和解决问题下一篇Automatisch Webhooks 使用指南内置零认证的 HTTP 触发器与请求响应机制创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?
咨询建站