当前位置: 首页 > news >正文

CMake解析参数用法示例

cmake_parse_arguments 是 CMake 中用于解析函数或宏参数的工具,特别适合处理带有选项(OPTIONS)、单值参数(SINGLE_ARGS)和多值参数(MULTI_ARGS)的复杂参数列表。以下是用法说明和一个示例:


基本语法

cmake_parse_arguments(<PREFIX>          # 解析后变量的前缀"<OPTIONS>"       # 选项列表(如 --enable-foo)"<SINGLE_ARGS>"   # 单值参数列表(如 --key VALUE)"<MULTI_ARGS>"    # 多值参数列表(如 --files a.txt b.txt)${ARGN}           # 需要解析的参数(通常用 ${ARGN})

解析后,可以通过以下变量访问参数:

  • 选项: ${<PREFIX>_<OPTION_NAME>}(值为 TRUE/FALSE
  • 单值参数: ${<PREFIX>_<SINGLE_ARG_NAME>}
  • 多值参数: ${<PREFIX>_<MULTI_ARG_NAME>}

示例

假设我们需要定义一个宏 setup_project,支持以下参数:

  • 选项: ENABLE_TEST(是否启用测试)
  • 单值参数: VERSION(项目版本号)
  • 多值参数: SOURCES(源文件列表)
代码实现
# 定义宏
macro(setup_project)# 解析参数set(OPTIONS "ENABLE_TEST")        # 选项列表set(SINGLE_ARGS "VERSION")        # 单值参数列表set(MULTI_ARGS "SOURCES")         # 多值参数列表cmake_parse_arguments("ARG"                         # 前缀为 ARG"${OPTIONS}""${SINGLE_ARGS}""${MULTI_ARGS}"${ARGN}                       # 传入宏的参数)# 检查是否有未解析的参数(可选)if(ARG_UNPARSED_ARGUMENTS)message(WARNING "Unknown arguments: ${ARG_UNPARSED_ARGUMENTS}")endif()# 处理选项if(ARG_ENABLE_TEST)message(STATUS "Testing enabled")# 添加测试相关逻辑...endif()# 处理单值参数if(ARG_VERSION)message(STATUS "Project version: ${ARG_VERSION}")else()message(FATAL_ERROR "VERSION must be specified!")endif()# 处理多值参数if(ARG_SOURCES)message(STATUS "Source files: ${ARG_SOURCES}")# 添加编译目标...add_executable(my_app ${ARG_SOURCES})else()message(FATAL_ERROR "SOURCES must be specified!")endif()
endmacro()# 调用示例
setup_project(ENABLE_TESTVERSION 1.0.0SOURCES src/main.cpp src/utils.cpp
)

输出结果

-- Testing enabled
-- Project version: 1.0.0
-- Source files: src/main.cpp;src/utils.cpp

注意事项

  1. 变量作用域:如果使用 macro 而非 function,解析后的变量会影响父作用域。建议在函数中使用 function + PARENT_SCOPE 控制作用域。
  2. 参数顺序:CMake 不关心参数顺序,但需要确保参数名和值正确匹配。
  3. 未解析参数:通过 ${<PREFIX>_UNPARSED_ARGUMENTS} 可以捕获未知参数。

通过 cmake_parse_arguments,你可以更灵活地处理 CMake 函数/宏的复杂参数!


你提到的这一点非常重要!在 CMake 中,宏(macro)函数(function)的行为有本质区别(尤其是作用域规则不同)。以下我会详细解释它们的差异,并给出一个函数的例子,同时说明为何在之前的回答中选择了宏。


为什么先用了宏(macro)的例子?

  1. 简化示例
    在简单的示例中,宏的变量作用域规则(直接修改父作用域)可以让代码更简洁,不需要额外处理变量传递。对于新手来说,这可能更容易理解。

  2. 历史原因
    早期 CMake 版本中,cmake_parse_arguments 在函数中的行为需要更谨慎的作用域处理,而宏的行为更“直接”。

但实际项目中,**函数(function)**通常是更安全的选择,因为它能隔离作用域,避免变量污染。


函数(function)的示例

以下是将之前的 setup_project 从宏改为函数的实现,并修复作用域问题:

代码实现
# 定义函数
function(setup_project)# 解析参数set(OPTIONS "ENABLE_TEST")        # 选项列表set(SINGLE_ARGS "VERSION")        # 值参数列表set(MULTI_ARGS "SOURCES")         # 多值参数列表cmake_parse_arguments("ARG"                         # 前缀为 ARG"${OPTIONS}""${SINGLE_ARGS}""${MULTI_ARGS}"${ARGN}                       # 传入函数的参数)# 检查未解析的参数(可选)if(ARG_UNPARSED_ARGUMENTS)message(WARNING "Unknown arguments: ${ARG_UNPARSED_ARGUMENTS}")endif()# 处理选项if(ARG_ENABLE_TEST)message(STATUS "Testing enabled")# 启用测试逻辑(例如 include(CTest)endif()# 处理单值参数if(NOT ARG_VERSION)message(FATAL_ERROR "VERSION must be specified!")endif()message(STATUS "Project version: ${ARG_VERSION}")# 处理多值参数if(NOT ARG_SOURCES)message(FATAL_ERROR "SOURCES must be specified!")endif()message(STATUS "Source files: ${ARG_SOURCES}")# 关键点:将变量传递到父作用域(如果需要影响外部)# 例如,将源文件列表传递给父作用域:set(SOURCES ${ARG_SOURCES} PARENT_SCOPE)# 在函数内创建目标(变量直接可见)add_executable(my_app ${ARG_SOURCES})
endfunction()# 调用示例
setup_project(ENABLE_TESTVERSION 1.0.0SOURCES src/main.cpp src/utils.cpp
)

宏(macro) vs 函数(function)的关键区别

特性宏(macro)函数(function)
作用域直接修改父作用域的变量默认只在函数内部作用域有效
变量传递自动“泄漏”到父作用域需显式使用 set(... PARENT_SCOPE)
性能类似代码替换,可能更高效有独立作用域,稍复杂
安全性容易污染父作用域变量隔离作用域,更安全

为什么推荐使用函数?

  1. 避免变量污染
    函数不会意外覆盖父作用域的变量(例如,如果父作用域中已经有一个 VERSION 变量,宏可能会直接修改它,而函数不会)。

  2. 逻辑隔离
    函数内部的操作(如 add_executable)默认只在函数作用域内生效,除非显式传递变量到父作用域。

  3. 可维护性
    函数的隔离性使得代码行为更可预测,适合复杂项目。


何时使用宏?

  1. 需要直接修改父作用域
    例如,在顶层脚本中快速操作变量。
  2. 简单代码替换
    当逻辑非常简单且不需要隔离作用域时。

总结

  • 如果你的目标是封装一个可复用的逻辑模块,优先使用函数
  • 如果示例中使用了宏,可以补充一个函数的版本,明确说明作用域处理的差异。这样用户可以根据实际需求选择。

这段代码的目的是通过两次调用 cmake_parse_arguments 实现一种嵌套参数解析的机制。它的核心思路是:先解析外层的“元参数”(定义如何解析内层参数),再用这些元参数去解析实际传递的参数。以下是对代码的详细解释,以及这种设计的优缺点分析。


代码解释

function(nuttx_parse_function_args)cmake_parse_arguments(IN "" "FUNC""OPTIONS;ONE_VALUE;MULTI_VALUE;REQUIRED;ARGN" "${ARGN}")cmake_parse_arguments(OUT "${IN_OPTIONS}" "${IN_ONE_VALUE}""${IN_MULTI_VALUE}" "${IN_ARGN}")if(OUT_UNPARSED_ARGUMENTS)message(FATAL_ERROR "${IN_NAME}: unparsed ${OUT_UNPARSED_ARGUMENTS}")endif()foreach(arg ${IN_OPTIONS} ${IN_ONE_VALUE} ${IN_MULTI_VALUE})set(${arg}${OUT_${arg}}PARENT_SCOPE)endforeach()endfunction()
1. 函数定义
function(nuttx_parse_function_args)

定义了一个名为 nuttx_parse_function_args 的函数,目的是封装一个通用的参数解析工具。


2. 第一次解析:cmake_parse_arguments(IN ...)
cmake_parse_arguments(IN ""                   # 外层无选项(OPTIONS)"FUNC"               # 外层单值参数(SINGLE_ARGS)"OPTIONS;ONE_VALUE;MULTI_VALUE;REQUIRED;ARGN"  # 外层多值参数(MULTI_ARGS)"${ARGN}"            # 输入的参数列表
)
  • 目的:解析外层的“元参数”,这些参数定义了如何解析内层的实际参数。
  • 解析结果
    • IN_FUNC: 单值参数,表示实际要解析的函数名(可能用于错误提示)。
    • IN_OPTIONS: 多值参数,定义内层参数的选项(OPTIONS)。
    • IN_ONE_VALUE: 多值参数,定义内层参数的单值参数(SINGLE_ARGS)。
    • IN_MULTI_VALUE: 多值参数,定义内层参数的多值参数(MULTI_ARGS)。
    • IN_ARGN: 多值参数,保存实际需要解析的内层参数列表。

3. 第二次解析:cmake_parse_arguments(OUT ...)
cmake_parse_arguments(OUT "${IN_OPTIONS}"      # 内层选项(来自第一次解析的 IN_OPTIONS)"${IN_ONE_VALUE}"    # 内层单值参数(来自第一次解析的 IN_ONE_VALUE)"${IN_MULTI_VALUE}"  # 内层多值参数(来自第一次解析的 IN_MULTI_VALUE)"${IN_ARGN}"         # 实际需要解析的参数(来自第一次解析的 IN_ARGN)
)
  • 目的:用第一次解析得到的元参数(IN_OPTIONS, IN_ONE_VALUE, IN_MULTI_VALUE)去解析实际的内层参数(IN_ARGN)。
  • 解析结果
    • OUT_<OPTION>: 内层选项的值(TRUE/FALSE)。
    • OUT_<SINGLE_ARG>: 内层单值参数的值。
    • OUT_<MULTI_ARG>: 内层多值参数的值。

4. 错误检查
if(OUT_UNPARSED_ARGUMENTS)message(FATAL_ERROR "${IN_NAME}: unparsed ${OUT_UNPARSED_ARGUMENTS}")
endif()
  • 检查是否有未解析的参数,如果有则报错。

5. 将解析结果传递到父作用域
foreach(arg ${IN_OPTIONS} ${IN_ONE_VALUE} ${IN_MULTI_VALUE})set(${arg}${OUT_${arg}}PARENT_SCOPE)
endforeach()
  • 将内层解析得到的参数值(OUT_<arg>)传递到父作用域,使得调用者可以访问这些参数。

为什么使用两次解析?

这种设计的关键在于动态定义参数解析规则

  1. 外层解析:定义内层参数的解析规则(哪些是选项、单值参数、多值参数)。
  2. 内层解析:根据外层解析得到的规则,解析实际的参数列表。

例如,假设调用代码如下:

nuttx_parse_function_args(FUNC my_functionOPTIONS ENABLE_FOOONE_VALUE VERSIONMULTI_VALUE SOURCESARGN ENABLE_FOO VERSION 1.0.0 SOURCES a.cpp b.cpp
)
  • 外层解析会提取 OPTIONS ENABLE_FOO, ONE_VALUE VERSION, MULTI_VALUE SOURCES,并将 ENABLE_FOO VERSION 1.0.0 SOURCES a.cpp b.cpp 保存到 IN_ARGN
  • 内层解析会根据外层解析的规则,将 ENABLE_FOO 解析为选项,VERSION 解析为单值参数,SOURCES 解析为多值参数。

优点

  1. 灵活性
    允许动态指定参数解析规则,可以复用同一个函数解析不同结构的参数。
  2. 通用性
    适合需要为多个函数或宏统一封装参数解析逻辑的场景。
  3. 减少重复代码
    避免在每个函数中重复编写 cmake_parse_arguments

缺点

  1. 复杂度高
    嵌套解析逻辑难以理解,尤其是对 CMake 新手。
  2. 依赖外层参数的正确性
    如果外层参数(如 OPTIONS, ONE_VALUE)未正确传递,内层解析会失败。
  3. 错误处理困难
    嵌套解析可能导致错误信息不直观(例如,外层参数错误和内层参数错误混杂)。
  4. 变量作用域问题
    需要显式传递变量到父作用域,容易遗漏或出错。

改进建议

  1. 添加注释
    明确说明两次解析的目的,尤其是外层参数的含义。
  2. 严格的错误检查
    在外层解析后检查必要的元参数(如 FUNC, OPTIONS 是否存在)。
  3. 示例和文档
    提供调用示例和文档,说明如何正确传递外层和内层参数。
  4. 简化设计
    如果不需要动态定义解析规则,应优先使用单次 cmake_parse_arguments

总结

这段代码通过两次 cmake_parse_arguments 实现了一种动态参数解析机制,虽然灵活但复杂度较高。在实际项目中,应权衡灵活性和可维护性:如果不需要动态指定解析规则,应避免嵌套解析;若必须使用,需确保充分的错误处理和文档支持。

http://www.xdnf.cn/news/231301.html

相关文章:

  • 【模型量化】量化基础
  • 大连理工大学选修课——机器学习笔记(7):集成学习及随机森林
  • 三生原理与中华文明标识体系的关系?
  • vs2019编译occ7.9.0时,出现fatal error C1060: compiler is out of heap space
  • C++(初阶)(十六)——set
  • YOLO视觉模型可视化训练与推理测试工具
  • 嵌入式中常用的算法介绍
  • (Go Gin)Gin学习笔记(五)会话控制与参数验证:Cookie使用、Sessions使用、结构体验证参数、自定义验证参数
  • 自动驾驶-一位从业两年的独特视角
  • 2025年-redis(p1-p10)
  • Kotlin与Jetpack Compose的详细使用指南
  • 高级java每日一道面试题-2025年4月30日-基础篇[反射篇]-如何防止你的类被通过反射非法实例化?
  • PCI总线数据采集卡 32路多功能异步模拟量信号采集卡
  • 如何在 Go 中实现各种类型的链表?
  • 硬盘分区丢失≠末日!3步逻辑恢复法+物理修复全流程图解
  • 大数据应用开发和项目实战-Seaborn
  • 使用通义千问大模型做结构化输出报错的分析
  • ubantu部署yolov5(第四集:模型加速)
  • 正点原子STM32H743单片机实现ADC多通道检测
  • k8s平台:手动部署Grafana
  • SQL命令二:SQL 高级查询与特殊算法
  • Git从入门到精通-第一章-基础概念
  • 软件性能测试有多关键?能找出潜在问题并确保其顺利运行吗?
  • [250430] Kali Linux 存储库密钥丢失导致所有用户无法正常更新 APT
  • JavaScript:从JS的执行机制到location对象
  • 大语言模型(LLM)应用开发平台Dify详细使用
  • 系统思考:局部最优与全局失衡
  • WHAT - Tailwind CSS + Antd = MetisUI组件库
  • GEO vs SEO:从搜索引擎到生成引擎的优化新思路
  • vs2019 调试看不到std::list 中的值,