CMake将add_library移至上层目录后，INTERFACE_LINK_LIBRARIES中PRIVATE库异常

这是你当前使用的CMake 3.15.5版本存在的已知内部缺陷，并非你的CMake配置逻辑错误导致。

你看到的avcodec::@<0x2aaeb30>这类带十六进制后缀的条目，是CMake内部对内存中目标对象的唯一缓存标识，正常流程下这类标识只存在于运行时的内存态目标属性中，生成安装配置文件时必须被完全剥离，不应该出现在导出的文本配置里。

• 该缺陷的触发条件和你观察到的现象完全匹配：提前在顶层/上层目录创建空库目标（add_library(Foo "")），后续递归进入子目录时再为目标追加PRIVATE类型的链接依赖。
• 当目标创建时机过早，和后续加载外部依赖、内部子目标的时机存在跨目录延迟时，CMake 3.15版本的内部缓存追踪逻辑会出现错位，在处理PRIVATE依赖对应的$<LINK_ONLY:...>生成表达式时，错误把内部缓存ID拼接到了依赖名称后面。
• 你观察到的“把add_library放回Fuz目录就恢复正常”的表现，本质是目标创建和后续属性配置的时机相邻，不会触发内部缓存的错位逻辑。
• PUBLIC段的依赖会走另一套独立的导出处理路径，完全不经过这个有缺陷的代码分支，所以不会出现这类冗余后缀。

• 优先选择：升级CMake到3.16及以上版本，该版本已经修复了空目标提前创建、后续追加属性时错误导出内部缓存ID的问题，同套配置在3.20及以上版本下生成的安装配置文件不会出现十六进制后缀。
• 临时方案（无法升级版本时）：在完成所有target_sources、target_link_libraries、target_include_directories的配置，执行install(EXPORT)生成配置文件之前，手动遍历Foo目标的INTERFACE_LINK_LIBRARIES属性，移除所有匹配::@<0x[0-9a-f]+>格式的冗余后缀。
• 你当前的整体配置思路完全符合CMake官方推荐的“顶层定义聚合目标、子目录追加源文件与属性”的最佳实践，不存在配置方式的错误。

内容的提问来源于stack exchange，提问作者schrödinbug