Question

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

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

$ {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"
)

对我来说，所有这些链接库都完全解析为主机上的路径对我来说真的很可疑。

我想的问题是：cmake是安装在要分发的前缀上，这只是一个不好的例子，还是要与“安装”它们的计算机绑定？就是前缀是否真的意味着只是要重新定位应该在系统上“安装”的位置，而我希望将其用作共享软件包管理器可能会出现问题？

Answer 1

是的，导出的CMake目标可以“分发”，但是该项目应遵循一些原则来实现。

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

如果链接库随编译器一起交付（例如target_link_libraries或m），事情很简单：只需传递库的名称转到rt。

如果链接的库YYY来自其他软件包，并且被target_link_libraries检测到，则这意味着以下几点：

脚本find_package(YYY)或FindYYY.cmake应该返回 IMPORTED 目标。如果不是这样，您可以尝试将其结果包装到 IMPORTED 目标中。

YYYConfig.cmake应该使用此 IMPORTED 目标。

您的项目附带的

脚本target_link_libraries应该使用find_dependency(YYY)来发现用户计算机上的库。

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

导出（安装）的cmake目标是否可分发？

1 个答案: