【问题标题】:Should I use add_subdirectory or find_package?我应该使用 add_subdirectory 还是 find_package?
【发布时间】:2016-06-28 16:35:00
【问题描述】:

我有一些项目遵循这个依赖图:

Executable
Main 
Libraries A, B, and C


Main //_Depends_A_B_C

A //_Depends_B

B

C //Depends_B

创建一个使用add_subdirectory 将A、B 和C 放在全局范围内并将它们链接在一起的超级项目对我来说更有意义吗?

Proj/

CMakeList.txt // Has add_subdirectory for each directory in b,a,c,Main order.

a/

b/

c/

Main/

或者我是否应该为他们制作find_package 解决方案的麻烦。

Main/

A/   //Installed to system

B/   //Installed to system

C/   //Installed to system

这些库正在开发中,因此很高兴能够在我的 IDE 中将它们全部视为一个项目,但我不想滥用add_subdirectory 来适应我的特定开发工具。

【问题讨论】:

  • 两种方法都有效。选择取决于您(也就是说,主要是主观的)。正如您已经注意到的,使用add_subdirectory 比使用find_package 更简单。如果你想要一个所有优点和缺点的列表,这样的列表会很大,所以它不适合 Stack Overflow。
  • 第三种可能是ExternalProject_Add()。一般来说,当您设置构建环境时,您应该考虑以下三个主题:1. Dependecies / Coupling,2. Deployment,3. Teams。有关“最佳 CMake 项目结构”的一些讨论,请参阅 hereherehere
  • @Alexis:你什么意思?您链接中的博客没有提及“超级项目”。
  • 看来add_subdirectory 是一种反模式,应该避免用于树外模块。 find_package() 是很好的模式,即使它需要使用自定义 Find*.cmake 来指示模块在哪里(因为正如 OP 所说,他不想安装库)。我不了解自己。我正在阅读很多内容以找到 CMake 的最佳实践。
  • 这确实不是主题,但我认为您也应该考虑externalproject_add。我认为它是find_packageadd_subdirectory 更好的替代品。

标签: cmake


【解决方案1】:

如果依赖是第三方的,那么你应该使用find_package。这允许某人将您的依赖项替换为系统提供的依赖项。在编写可能包含在包管理器中的库时,这一点很重要,例如 vcpkg 或 Linux 发行版的标准存储库。

如果依赖项可能是相对于您的代码进行交叉编译的(例如,它是构建时工具或像 Bison 这样的代码生成器),那么您必须使用find_package。在给定的 CMake 构建期间,可能只有一个工具链处于活动状态。

如果您将依赖项存储在存储库中(直接或作为子模块),那么使用 ExternalProject 的超级构建设置可能会很方便。您的顶级项目将仅包含外部项目编排,并且每个子项目将安装到本地前缀,并查找具有相同前缀的包。请参阅CMAKE_INSTALL_PREFIXCMAKE_PREFIX_PATH 了解更多详情。

在任何其他情况下,首选add_subdirectory

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-09-05
    • 1970-01-01
    • 2015-10-16
    • 2023-03-06
    • 2013-02-20
    • 2011-07-31
    相关资源
    最近更新 更多