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

注意事项

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

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

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

为什么先用了宏（macro）的例子？

简化示例：
在简单的示例中，宏的变量作用域规则（直接修改父作用域）可以让代码更简洁，不需要额外处理变量传递。对于新手来说，这可能更容易理解。
历史原因：
早期 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)`
性能	类似代码替换，可能更高效	有独立作用域，稍复杂
安全性	容易污染父作用域变量	隔离作用域，更安全

为什么推荐使用函数？

避免变量污染：
函数不会意外覆盖父作用域的变量（例如，如果父作用域中已经有一个 VERSION 变量，宏可能会直接修改它，而函数不会）。
逻辑隔离：
函数内部的操作（如 add_executable）默认只在函数作用域内生效，除非显式传递变量到父作用域。
可维护性：
函数的隔离性使得代码行为更可预测，适合复杂项目。

何时使用宏？

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

总结

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

这段代码的目的是通过两次调用 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>）传递到父作用域，使得调用者可以访问这些参数。

为什么使用两次解析？

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

外层解析：定义内层参数的解析规则（哪些是选项、单值参数、多值参数）。
内层解析：根据外层解析得到的规则，解析实际的参数列表。

例如，假设调用代码如下：

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 解析为多值参数。