C++ 项目组织(使用 gtest、cmake 和 doxygen)

Question

我一般是编程新手，所以我决定从用 C++ 制作一个简单的 vector 类开始。不过，我想从一开始就养成良好的习惯，而不是以后尝试修改我的工作流程。

我目前只有两个文件 vector3.hpp 和 vector3.cpp。随着我对一切变得更加熟悉，这个项目将慢慢开始增长(使其更像是一个通用线性代数库)，所以我想采用“标准”项目布局，让以后的生活更轻松。所以环顾四周后，我发现了两种组织 hpp 和 cpp 文件的方法，第一种是:

project
└── src
    ├── vector3.hpp
    └── vector3.cpp

第二个是:

project
├── inc
│   └── project
│       └── vector3.hpp
└── src
    └── vector3.cpp

您会推荐哪个以及为什么？

其次，我想使用 Google C++ 测试框架对我的代码进行单元测试，因为它看起来相当容易使用。您是否建议将此与我的代码捆绑在一起，例如在 inc/gtest 或 contrib/gtest 文件夹中？如果捆绑，您建议使用 fuse_gtest_files.py 脚本来减少数量或文件，还是保持原样？如果没有捆绑，这个依赖如何处理？

在编写测试时，这些通常是如何组织的？我在想每个类都有一个 cpp 文件(例如 test_vector3.cpp)，但都编译成一个二进制文件，这样它们就可以很容易地一起运行？

由于 gtest 库通常是使用 cmake 和 make 构建的，我在想我的项目也像这样构建是否有意义？如果我决定使用以下项目布局:

├── CMakeLists.txt
├── contrib
│   └── gtest
│       ├── gtest-all.cc
│       └── gtest.h
├── docs
│   └── Doxyfile
├── inc
│   └── project
│       └── vector3.cpp
├── src
│   └── vector3.cpp
└── test
    └── test_vector3.cpp

CMakeLists.txt 的外观如何才能仅构建库或库和测试？此外，我还看到不少具有 build 和 bin 目录的项目。构建是否发生在构建目录中，然后二进制文件移出到 bin 目录中？测试和库的二进制文件会在同一个地方吗？或者将其结构如下更有意义:

test
├── bin
├── build
└── src
    └── test_vector3.cpp

我还想使用 doxygen 来记录我的代码。是否可以使用 cmake 和 make 自动运行它？

很抱歉问了这么多问题，但我还没有找到一本关于 C++ 的书可以令人满意地回答这些类型的问题。

Answer 1

C++ 构建系统有点玄学，而且项目越老你能找到更多奇怪的东西，所以很多东西并不奇怪的问题出现。我将尝试一一解决问题，并提及有关构建 C++ 库的一些一般性事项。

分隔目录中的头文件和 cpp 文件。这只是如果您正在构建应该使用的组件，则必不可少作为一个库而不是一个实际的应用程序。你的标题是用户与您提供的产品进行交互的基础，并且必须是安装。这意味着它们必须位于子目录中(没有人想要许多标题以顶级 /usr/include/) 和您的 header 必须能够在这样的设置中包含自己。

└── prj
    ├── include
    │   └── prj
    │       ├── header2.h
    │       └── header.h
    └── src
        └── x.cpp

效果很好，因为包含路径可以解决，您可以轻松使用安装目标的通配符。

捆绑依赖:我认为这在很大程度上取决于构建系统来定位和配置依赖关系以及如何将您的代码依赖于单个版本。这也取决于如何您的用户的能力以及在其上安装依赖项的难易程度平台。 CMake 为 Google 提供了一个 find_package 脚本测试。这使事情变得容易得多。我只会捆绑必要时避免使用。

如何构建:避免源内构建。 CMake 使用源代码构建容易，它让生活更轻松。

我想您还想使用 CTest 为您的系统运行测试(它还附带了对 GTest 的内置支持)。一个重要的决定目录布局和测试组织将是:你最终得到子项目？如果是这样，您在设置 CMakeLists 时需要做更多的工作并且应该将您的子项目拆分为子目录，每个子目录都有其自己的 include 和 src 文件。也许甚至他们自己的doxygen运行和输出(组合多个 doxygen 项目是可能的，但并不容易或漂亮)。

你会得到这样的结果:

└── prj
    ├── CMakeLists.txt <-- (1)
    ├── include
    │   └── prj
    │       ├── header2.hpp
    │       └── header.hpp
    ├── src
    │   ├── CMakeLists.txt <-- (2)
    │   └── x.cpp
    └── test
        ├── CMakeLists.txt <-- (3)
        ├── data
        │   └── testdata.yyy
        └── testcase.cpp

在哪里

• (1) 配置依赖项、平台细节和输出路径
• (2) 配置你要构建的库
• (3) 配置测试可执行文件和测试用例

如果您有子组件，我建议您添加另一个层次结构并为每个子项目使用上面的树。然后事情就变得棘手了，因为您需要决定子组件是搜索和配置它们的依赖关系，还是在顶层进行。这应根据具体情况决定。

Doxygen:在你成功完成了配置舞蹈之后doxygen，使用 CMake add_custom_command 添加一个文档目标。

这就是我的项目的最终结果，我见过一些非常相似的项目，但当然这不是万能的。

附录在某些时候你会想要生成一个 config.hpp包含版本定义的文件，可能还有某个版本的定义控制标识符(Git 哈希或 SVN 修订号)。 CMake 有自动查找该信息并生成的模块文件。您可以使用 CMake 的 configure_file 替换变量在 CMakeLists.txt 中定义变量的模板文件。

如果您正在构建库，您还需要一个导出定义以正确区分编译器，例如MSVC 上的 __declspec和 GCC/clang 上的 visibility 属性。