CMake：强制命名空间和库文件名之间的关系答案

【问题标题】：CMake: enforcing a relationship between namespaces and library file namesCMake：强制命名空间和库文件名之间的关系
【发布时间】：2014-11-16 23:44:47
【问题描述】：

CMake 似乎不支持定义导出或安装目标的命名空间与相应库文件的名称之间的关系。

因此，例如，CMake 可以轻松创建包含明确命名目标的包，例如 MyOrg::MyLibrary（使用 export(EXPORT ...) 和 install(EXPORT ...) 命令的 NAMESPACE 选项，但实际的 .a, . lib、.so 或 .dll 文件仍将获得全局间隔名称，例如 libMyLibrary.a：命名空间不会进入库文件名。

当然可以自己将命名空间应用于您的目标；在上面的示例中，您可以将目标命名为 MyOrgMyLibrary，从而得到一个库文件名，例如“libMyOrgMyLibrary.a”。我猜这没关系，除了这使得NAMESPACE 选项基本上无用（或者你最终会得到名为MyOrg::MyOrgMyLibrary 的目标），让我觉得我错过了一些东西。

有没有办法覆盖生成的库的名称？或者使用 CMake 确保库文件获得明确名称的“正确”方法是什么？

【问题讨论】：

标签： namespaces cmake packages libraries

【解决方案1】：

整个命名空间的功能远没有名字所暗示的那么强大。它实际上只不过是一个命名约定。我看到了带有大量库（如Qt）的大型框架的主要优势，但你是对的，它本身并没有太大用处。

另请注意，该机制仅关注避免 CMake 脚本中的名称冲突，不关注文件系统上的名称冲突。后者需要在另一个层面上解决。避免这些问题的最简单方法当然是将库安装到子目录中。然后你几乎只需要担心你自己项目中的名称冲突。不幸的是，这种方法有其自身的缺点。在 Unix 上，不鼓励用户创建到 /usr/lib 的子目录，但存储应用程序特定库除外（感谢 @JPNotADragon for pointing this out）。

否则，您已经提到过像前缀这样的常用技术。

我同意，这个功能并不像人们希望的那样强大。但话又说回来，名称冲突是一个不平凡的问题，最终合理的命名约定可能仍然是最好的解决方案。

【讨论】：

再次嗨 ComicSansMS，感谢您的见解。关于将库安装到子目录 - 我查看了 FHS（Linux 标准库），它说 lib 目录下的子目录是为特定于应用程序的库保留的。快速浏览一下我的 Linux 服务器的usr/lib 似乎证实了这一点。这实际上会给我们留下前缀作为唯一剩下的选择。
@JPNotADragon 很好地发现了 FHS。我会将其纳入答案中。
CppTemplates project 已更新（不再有命名空间）

【解决方案2】：

有没有办法覆盖生成的库的名称？

是的。请参阅OUTPUT_NAME 属性。

可以想象，您可以将其包装在一个函数中（未经测试；应该给您正确的想法，但可能包含错误）：

function(my_add_library NAME)
  add_library(${NAME} ${ARGN})
  set_target_properties(${NAME} PROPERTIES OUTPUT_NAME my_${NAME})
endfunction()

【讨论】：