导出（安装）的cmake目标是否可分发？ [英] Are exported (installed) cmake targets distributable?

问题描述

我正在一个项目中包含很多外部依赖项，这些依赖项包含在项目树中。我想预先构建所有依赖项，并在项目树中共享可导入的目标。

I'm working on a project with a lot of external dependencies, which are included in the project tree. I would like to pre-build all of the dependencies and share the importable targets within the project tree.

我打算在源代码树中将cmake install与CMAKE_INSTALL_PREFIX一起使用，并使用CMAKE_PREFIX_PATH为find_package引用它。但是，我开始怀疑该策略的可维护性如何？例如，在已安装的cmake脚本之一中，我注意到以下内容：

I was planning to use cmake install with a CMAKE_INSTALL_PREFIX in the source tree, and use CMAKE_PREFIX_PATH to reference it for find_package. However, I'm beginning to wonder how maintainable this strategy is going to be? For example here's something I noticed in one of the installed cmake scripts:

$ {CMAKE_PREFIX_PATH} /lib/cmake/glfw3/glfw3Targets.cmake：

set_target_properties(glfw PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libm.so;dl;/usr/lib/x86_64-linux-gnu/libX11.so;-lpthread"
)

对我来说，所有这些链接库都已完全解析为路径，这真让我感到怀疑。

It seems really suspicious to me that all of those link libraries are fully resolved to paths on the host machine.

我想问题是：cmake是否安装在要可分发的前缀上，这只是一个不好的例子，还是要捆绑在一起到您安装它们的机器上？就是前缀真的是真的只是要重新定位应该在系统上安装的位置，而我希望将其用作共享软件包管理器可能有问题吗？

I guess the question is: Are cmake installs to a prefix meant to be distributable and this is just a bad example, or are they meant to be tied to the machine you "install" them on? Ie. Is prefix really meant to just relocate where on the system things are supposed to be "installed", and my hope to use it as a shared package manager likely to be problematic?

推荐答案

是的， EXPORT 编辑的CMake目标可以是可分发的，但是该项目应遵循一些原则来实现。

Yes, EXPORT'ed CMake targets can be "distributable", but the project should follow some principles for achieve that.

如果您链接到（外部）库，但不希望导出文件包含指向该库的绝对路径，则不要直接将绝对路径传递给到 target_link_libraries 。

If you link with a (external) library, but do not want export file to contain absolute path to it, then do not pass absolute path directly to target_link_libraries.

如果链接库被附带了编译器（例如， m 或 rt ），事情很简单：只需将库的名称传递给 target_link_libraries 。

In case a linked library is shipped with a compiler (e.g. m or rt), things are simple: just pass the library's name to the target_link_libraries.

如果链接库YYY来自其他程序包，并且被检测到find_package（YYY），这意味着几件事：

In case a linked library YYY comes from other package and is detected by find_package(YYY), this implies several things:

1. 脚本 FindYYY.cmake 或 YYYConfig.cmake 应该返回 IMPORTED 目标。如果不正确，则可以尝试将其结果包装到 IMPORTED 目标中。

1. Script FindYYY.cmake or YYYConfig.cmake should return IMPORTED target. If this is not true, you may try to wrap its results into IMPORTED target.

target_link_libraries 应该使用此 IMPORTED 目标。

脚本 XXXConfig.cmake 您的项目附带的c $ c>应该使用 find_dependency（YYY）用于发现用户计算机上的库。

Script XXXConfig.cmake, shipped with your project, should use find_dependency(YYY) for discover a library on a user machine.

对于 find_dependency（YYY）工作，用户计算机应具有 FindYYY.cmake 或 YYYConfig.cmake 脚本。或者，您可以将 FindYYY.cmake 与项目一起发布，并在 find_dependency之前调整 CMAKE_MODULE_PATH 变量（）调用（在您的 XXXConfig.cmake 中）。

For find_dependency(YYY) work, a user machine should have FindYYY.cmake or YYYConfig.cmake script. Alternatively, you may ship FindYYY.cmake with your project, and adjust CMAKE_MODULE_PATH variable before find_dependency() call (in your XXXConfig.cmake).

这篇关于导出（安装）的cmake目标是否可分发？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！