CMake报错：调用get_target_property于不存在的目标xyz

除target_link_libraries外，"xyz"可能的引用方式 #

• 其他CMake目标操作命令：比如add_dependencies直接关联目标依赖，target_compile_definitions、target_include_directories等命令直接指定了"xyz"；或者export(TARGETS ...)、install(TARGETS ...)中包含了"xyz"，即便条件编译未生成目标，这些命令仍可能执行。
• 自定义函数/模块的隐式遍历：像你提到的targetCompileOptions这类自定义函数，可能通过遍历全局目标列表（比如自定义的get_all_targets逻辑，或CMake内置的CMAKE_BUILD_SYSTEM_TARGETS变量），将"xyz"纳入处理范围；也可能是find_package引入了系统中已安装的同名外部目标。
• 条件编译漏判：主CMakeLists的关联代码虽被if(XYZ)控制，但子目录、其他模块中的代码未加对应判断，仍在引用"xyz"。
• CMake缓存残留：之前编译生成的缓存中保留了"xyz"的目标信息，导致后续CMake运行时误判目标存在。

排查步骤 #

• 全局搜索CMake代码：在项目根目录执行命令grep -r "xyz" --include="*.cmake" --include="CMakeLists.txt" ./，找出所有包含"xyz"的CMake命令，检查哪些未被if(XYZ)条件包裹。
• 分析自定义函数逻辑：查看env/targetCompileOptions.cmake的实现，确认它遍历链接目标的方式——比如是否通过get_target_property(main_target_link_libraries main LINK_LIBRARIES)获取依赖列表后遍历，检查该列表中出现"xyz"的原因。
• 清理CMake缓存：删除build目录下的CMakeCache.txt及所有自动生成的CMake文件，重新执行配置编译，排除缓存残留的干扰。
• 跟踪CMake执行流程：运行cmake .. --trace（或cmake .. --trace-expand），查看CMake执行的每一条命令，定位首次引用"xyz"的代码位置，梳理触发报错的路径。
• 生成目标依赖图：执行cmake --graphviz=targets.dot ..生成目标依赖图，通过可视化方式查看"xyz"的来源，确认是否存在外部依赖或间接引用。

内容的提问来源于stack exchange，提问作者Charles