CMakeLists.txt中find_package应该在哪里调用？

Question

在 cmake 项目中包含外部库通常使用

find_package()

来执行。

但是在大型多应用程序/多库项目中，某些第三方和/或系统库通常会被多个应用程序和库使用。

这些公共库的

find_package()

应该在哪里调用？

1. 在每个需要它们的可执行文件/库的

   CMakeLists.txt

   文件中？
2. 或者，在顶级

   CMakeLists.txt

   文件中？

第一个选项似乎是一种更加模块化的方法，但关联的

find_package()

脚本是为使用它们的每个库/可执行文件执行的。 这会减慢配置步骤。

第二个选项更有效，但对我来说看起来有点像全局变量。

Answer 1

我会区分可能是（或已经是）独立包的子项目/目录和那些专门反映源代码结构的子项目/目录。

• 在第一种情况下，

  find_package

  显然应该位于子目录

  CMakeLists.txt

  中，以允许提取子目录以进行独立构建或分发。配置步骤的低效率不应该成为这里关注的问题，因为构建的配置不会经常执行。

• 在第二种情况下，我更喜欢在顶层

  find_package

  中调用

  CMakeLists.txt

  。如果您不使用这些调用设置的变量来填充全局变量，而是使用

  target_link_libraries

  代替（如评论中建议的那样），那么这应该足够干净。但有时，找到的包不会导出正确的目标来链接，而是定义一些包含路径变量等。然后，应该很容易定义您自己的

  INTERFACE

  库，将这些标志/路径封装为使用要求，并在再次通过

  target_link_libraries

  链接时传递它们。

Answer 2

在引用包的 CMakeFiles.txt

 文件中调用 

find_package。参考资料可能包括

• 包的变量（例如头文件路径），或者
• 其目标，如

  target_link_libraries

  中所使用。

遵循类似的原则，例如包括您使用的内容和保持较小的范围，您应该致力于确保软件项目：

• Cohesive：该包在该 CMakeLists.txt 文件中使用，因此找到该包也属于该文件。这带来了模块化，使重新定位或重用文件变得更容易，并更容易地查看它使用的包。
• 解耦：遥远的 CMakeLists.txt 文件不会以可能令人惊讶或令人困惑的方式相互依赖。这使得更改一个 CMakeLists.txt 变得更容易，而不会破坏另一个中的功能。

请注意，虽然这种方法更加健壮、可扩展且可维护，但它至少同样冗长且繁琐。如果您更喜欢在根目录 CMakeLists.txt 中列出包，那么至少要保持一致并将它们全部放在一起。