0

遵循现代 CMake 指南（例如，参见https://www.slideshare.net/DanielPfeifer1/effective-cmake，尤其是幻灯片 46），我正在尝试PkgConfig.cmake为我的Pkg.

Pkg取决于Foo哪个又取决于Bar。既没有Foo也Bar没有配置文件——而是我正在使用FindFoo.cmake并FindBar.cmake找到它们。

我的PkgConfig.cmake文件看起来像这样

set(Pkg_LIBRARIES Pkg::Pkg)

include(CMakeFindDependencyMacro)

find_dependency(Foo)  # Use FindFoo.cmake find and import as target Foo::Foo
                      # Foo depends on Bar which is similarly imported using
                      # FindBar.cmake as target Bar::Bar

include("${CMAKE_CURRENT_LIST_DIR}/PkgTargets.cmake")

我的结果PkgTargets.cmake看起来像

add_library(Pkg::Pkg STATIC IMPORTED_
set_target_properties(Pkg::Pkg PROPERTIES
  INTERFACE_LINK_LIBRARIES "Foo::Foo")

# Load information for each installed configuration
.
.
.

我的问题是如何避免其他包导入Pkg到他们的项目中，而不必指定在哪里Foo，更重要Bar的是在哪里可以找到？

如果必须通过变量和或再次指定包的位置Foo，这是否会破坏构建传递依赖项的目的？BarFoo_ROOTBar_ROOTCMAKE_PREFIX_PATH

我的 Pkg 已经知道它是在哪里找到的，所以我应该解析/设置Foo_ROOT并将Bar_ROOT其放入我的PkgConfig.cmake文件中吗？

4

1 回答 1

1

我的问题是如何避免其他包导入Pkg到他们的项目中，而不必指定在哪里Foo，更重要Bar的是在哪里可以找到？

完全允许PkgConfig.cmake指定（提示）其依赖项的位置。

我的 Pkg 已经知道它是在哪里找到的，所以我应该解析/设置Foo_ROOT并将Bar_ROOT其放入我的PkgConfig.cmake文件中吗？

请注意，这些XXXConfig.cmake文件通常是为已安装的项目准备的，以便将其移动到构建机器上的其他目录中，或者更重要的是，将其复制到其他机器中并在那里使用。

因为另一台机器上的位置可能与构建机器上的位置不同，所以知道它们在构建机器上的位置无助于在目标机器上找到它们。FooBar

不过，由您（作为项目的开发人员）指定项目的使用限制。例如，您可以指定项目只能在构建它的机器上使用。Foo在这种情况下，Bar在脚本中重用构建位置PkgConfig.cmake是合理的。

此外，即使允许将已安装的项目复制到其他机器，您仍然可以使用构建位置Foo和Bar作为提示在PkgConfig.cmake. 因此，如果项目将在构建它的同一台机器上使用，那么将在没有用户干预的情况下找到依赖关系。如果将项目复制到与构建机器具有相同位置的另一台机器Foo上，情况也是如此。Bar

于 2020-01-30T09:59:34.683 回答