最近再次出现一个老问题：设置CMAKE_MODULE_PATH的正确方法是什么？但这几乎适用于任何列表。但是，一般文本可能会有所不同，但IMO仅在该文本可能包含分号时才有所不同。
前提条件：该变量可能未设置、为空或已设置
选项：
set (CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmakeModules ${CMAKE_MODULE_PATH})set (CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmakeModules" ${CMAKE_MODULE_PATH})list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmakeModules)list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmakeModules")if (NOT CMAKE_MODULE_PATH) set (CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmakeModules") else() set (CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmakeModules;${CMAKE_MODULE_PATH}") endif()
要包括一些推理：
a) 1.当路径中有空格时，可能会失败，因此必须使用 2。以避免这种情况。这是对的吗？
b) 3/4 看起来更好/更简洁。再次需要空间吗？
c) 5.有(丑陋的)特殊情况处理，1-4避免。这是必需的吗？
相关：cmake：何时引用变量？
但我仍然不确定何时使用引号，尤其是在处理路径和列表时。
奖励：评估过程中到底发生了什么？如果所有${...}在传递给函数之前都会被变量的值替换，那么例如以下内容将不起作用并且需要空格。但它确实按预期工作：
set(FOO_DIR "my space path")
set(CMAKE_LIST /usr)
set(CMAKE_LIST ${CMAKE_LIST} ${FOO_DIR}/foo)
oder: list(APPEND CMAKE_LIST ${FOO_DIR}/foo)
这也适用于对其他函数的调用。 例如：
set_target_properties(MYTARGET PROPERTIES
IMPORTED_LOCATION ${FOO_DIR}/foo
)
问题是：为什么？这在标准的什么地方指定？
set和list都可用于将值附加到列表：
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmakeModules)
或
set (CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}/cmakeModules)
第一种形式(带有"list")是首选，因为它更短并且不重复变量的名称。
结果列表不受引用附加值的影响。也就是说，在这种情况下，报价只是一个品味问题。
注 1：引用不仅影响特定情况(set和list命令)。在其他情况下，引用可能至关重要。
注2：如果当前路径包含分号(;)，则引用或不引用将被错误地处理。
为什么引号在这里毫无意义
假设变量A包含分号，例如
set(A "a/b;c/d")
治疗
${A}/cmakeModules
和
"${A}/cmakeModules"
传递给函数时不同：第一种情况被视为两个参数，但第二种情况被视为单个参数。您可以在message()调用中查看这种差异：
# give: a/bc/d/cmakeModules
message(STATUS ${A}/cmakeModules)
# give: a/b;c/d/cmakeModules
message(STATUS "${A}/cmakeModules")
但是这两种处理在命令list给出相同的效果：
set(B "m") # Initial value
# Either command below sets B to 3(!) values: m;a/b;c/d/cmakeModules
list(APPEND B ${A}/cmakeModules)
list(APPEND B "${A}/cmakeModules")
它可以被视为"CMake 变量包含扁平列表"。
a) True
b) 错误。是的，我也喜欢这种方式。
c) 假