c++ - cmake的困境

Question

我正在做一个 C++ 项目。到目前为止它并不复杂，但取决于一堆“流行”库(nlohmann/json、ToruNiina/toml11 仅举几例)。他们都有一些CMakeLists.txt从我经验不足的角度来看，我认为它们结构良好。
现在当然我可以一个一个地编译库，或者在我的项目存储库中包含一个“拷贝”，但我想做得更好。在研究了可用的构建工具后，我决定使用 cmake构建和管理 C++ 项目。 promise 是获得一个稳定的、广泛支持的工具，这将有助于简化和统一构建过程。而且，从项目性质上我没有特权对目标机器强加任何要求；我需要为部署打包所有东西。
我花了几天时间阅读、观看和测试各种 cmake 教程、手册和手册。我不得不承认，我很快开始觉得，一个应该澄清开发过程的工具不断引入新的晦涩之处，与其目的背道而驰。本来，我认为这是因为我缺乏经验，然而......
我读了 articles关于为什么不捆绑依赖，后面只有 methods of doing so .我发现建议使用一种方式 A 超过 B，C 超过 B，然后 A 超过 C。我花了一段时间才弄清楚 2.8 和 3.0 之间的差异，obscurity的 target_link_libraries , 设置 cxx 版本和/或编译器警告标志等。
我的观点是，即使在对 cmake 的海洋进行了令人筋疲力尽的探险之后，我仍然不确定一些基本问题:

How is cmake meant to be used?

What is a standard, what is a courtesy, and what is none of those?

How can I tell that something is a feature, an archaic backwards compatibility, or both?

现在我将在我的项目中说明这一点。我只需要这样的东西

cmake_minimum_required(VERSION 3.14)
project(CaseCore CXX)

add_executable(myBinary list/of/cpp/sources.cpp)
target_link_libraries(myBinary PUBLIC someExternalLibs likeForExample nlohmann_json::nlohmann_json oqs)

唯一的问题是库(反正没有其他问题的空间)。我想用项目构建它们并且不想制作本地拷贝(不要一直拖着大量不相关的文件)。首先，我创建了库 repos 的分支，以便拥有可靠的来源并能够将较新的版本合并到我的分支中。
现在决定是否使用 git submodule或其他一些方案，我读过 submodule 表现不佳，并且更喜欢由 cmake 管理整个事情独自的。我从 ExternalProject_Add 开始，但后来我发现了 FetchContent这帮助我轻松地将外部依赖项添加到我的 cmake 列表中

FetchContent_Declare(nlohmann
    GIT_REPOSITORY https://github.com/my-reliable-fork-of/json
    GIT_TAG v3.7.3
)
message(STATUS  "Fetching Json...this may take a while")
FetchContent_MakeAvailable(nlohmann)

看起来和工作得很好而且很小。但是，我总是必须搜索图书馆本身才能找到/猜测 哪个目标链接到我的可执行目标 ?似乎有接近于零的约定，除非各自的 CMakeLists.txt读起来很简单，我倾向于猜测目标名称，直到找到为止。
最近我想从 here 链接 liboqs并且上述情况并没有真正帮助；出于某种原因，我可以链接 oqs， #include "oqs/oqs.h" ，但未创建动态库并终止执行。我很确定我可以在另一段时间花费谷歌搜索和玩弄各种 cmake 变量后解决问题。然而这不是我所期望的方式 cmake帮助我管理我的项目；实际上恰恰相反。
为了清楚起见，我拒绝了其他方法，包括

add_subdirectory from local repo copy (git submodule)
ExternalProject_Add from local repo copy (git submodule)
ExternalProject_Add from online repo
find_package

因为它们似乎更加晦涩/老式等(尽管经过数小时的研究，它们似乎仍然与对我做同样事情的多种方法一样多)
现在我有

Am I doing something wrong, or is it really what working with cmake should look like?

Do I really have to "reverse-engineer" other people's CMakeLists in order to use a library?

Under these circumstances, how can I convince my coworkers to use similar work process?

最后

How can I adjust my work in order to ease these difficulities for others?

我越用越喜欢 C++。然而，我花了大量的生产时间来解决依赖关系……而且我不想让 this guy更生气了。

Answer 1

How is cmake meant to be used?

典型的 cmake 用法与旧的 autotools 用法相匹配:

$ cmake /path/to/src #replaces /path/to/src/configure
$ make
$ make install

一些目标发生了变化(例如， make check 与 make test )，并且 cmake 不提供所有相同的标准目标(例如， make distclean )，但我上面的用法是大多数开发人员会做的(因为 cmake重新运行，大多数情况下它实际上只是第二步)。

如果您的 CMakeLists.txt不支持这个工作流程，你应该有一个很好的理由。大多数工具都会采用这样的工作流程，因此您严重限制了自己。

What is a standard, what is a courtesy, and what is none of those?

除了上述之外，cmake 几乎是狂野的西部。由于更好的文档和培训，事情变得更加标准化，但它远非完美。

一个行为良好的 cmake 项目应该导出它的目标(在 Stack Overflow 上有很多关于这个的问题和答案)并传播标志和依赖项。这使得依赖项目使用导出的目标变得更加容易，幸运的是这很容易做到。

How can I tell that something is a feature, an archaic backwards compatibility, or both?

我所知道的任何事情都没有造成这些区别。一般来说，较新的方法利用 target_*函数而不是全局函数(例如， target_include_directories 与 include_directories )。 target_*函数还用于传播标志，包括目录、编译器功能和我上面提到的依赖库。

Am I doing something wrong, or is it really what working with cmake should look like?

您正在谈论管理外部依赖项，我将跳过这一点以避免发表意见。简而言之，C 和 C++ 依赖项很难，并且在项目中管理它们的方法很多。它们各有利弊，但大多数仍然是为作者的用例设计的。您必须弄清楚您需要哪些用例，并基于此选择工具和工作流程。

Do I really have to "reverse-engineer" other people's CMakeLists in order to use a library?

一个行为良好的 cmake 项目将正确导出其目标，即使它们使用与您不同的依赖管理。如果他们不这样做，请向项目发送拉取请求(导出并不难，学习如何做是很好的)或者只是针对他们提交错误，特别是如果他们已经使用 cmake 作为构建系统。

Under these circumstances, how can I convince my coworkers to use similar work process?

这取决于你的同事，里程会有所不同。我曾与希望采用最佳实践并支持灵活性的同事打交道，也曾与那些满足于只做足以解决我们目前面临的问题的同事打交道。