为何使用OpenSSL::SSL/Crypto是现代CMake做法而非${OPENSSL_LIBRARIES}？

先看这段CMake代码的修改建议：

-  PUBLIC ${OPENSSL_LIBRARIES}
+  PUBLIC OpenSSL::SSL OpenSSL::Crypto

很多CMake专家都认为后者是现代规范，哪怕OPENSSL_LIBRARIES在官方文档里并没有被弃用，核心原因不是变量"看起来混乱"，而是两者本质上的设计差异：

1. 传递依赖的自动处理 #

现代CMake的目标（比如OpenSSL::SSL）是包含完整属性的抽象实体，它不仅记录了库文件的路径，还内置了头文件目录、编译定义、链接顺序、甚至自身的依赖项等所有必要信息。当你把这类目标设为PUBLIC依赖时，CMake会自动将这些属性传递给所有依赖你的目标，完全不用手动去管理额外的相关变量，也不用操心OpenSSL自身依赖的其他库怎么添加。

而OPENSSL_LIBRARIES只是一个存储库路径的字符串变量，它只解决了"链接哪个库"的问题，头文件目录、编译选项、传递依赖都得你手动处理，稍不注意就会漏配置，导致编译错误。

2. 跨平台与配置兼容性更强 #

CMake的目标是统一的抽象层，不管是Windows下的动态库、Linux下的静态库，还是Debug/Release不同编译配置，CMake都会自动匹配对应版本的目标属性，不用你手动切换路径。

但OPENSSL_LIBRARIES里的路径是固定的，一旦换了编译环境、跨平台编译，这个变量里的路径很可能就失效了，得手动调整，灵活性极差。

3. 语义更清晰易懂 #

OpenSSL::SSL和OpenSSL::Crypto明确对应OpenSSL的两个核心功能模块，一眼就能看懂依赖的是什么组件。而OPENSSL_LIBRARIES是个模糊的集合变量，你得去查它具体包含哪些库，可读性和维护性都差很多。

正如现代CMake指南里提到的：

“现代CMake可以自动处理目标的传递依赖，这意味着你无需再纠结混乱的变量，使用libmodern所需的所有属性都会被正确处理。”

这种基于目标的依赖管理，才是现代CMake的核心设计理念，而变量式的用法属于传统CMake的遗留方式，虽然还能用，但已经不符合最佳实践了。

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