如何在合并测试位置的Pitch叉布局项目中使用介子？

Question

我对介子专家有一点挑战。

我最新的C++项目(一个库)是根据叉子布局构建的。正如该约定所允许的那样，我已经决定使用合并头和合并测试放置。这基本上意味着我的头文件、源文件和测试源文件都是同一个src目录结构的一部分。

此外，我的代码根据实现的目的被组织成多个子目录(例如实用程序、算法、容器、.)。

本质上，我所拥有的是(这只是一个例子)：

<project>
├── meson.build
└── src/<project>
    ├── algorithms
    │   ├── meson.build
    │   ├── sort.hpp
    │   ├── sort.cpp
    │   ├── sort.test.cpp
    │   ├── transform.hpp
    │   ├── transform.cpp
    │   └── transform.test.cpp
    ├── containers
    │   ├── meson.build
    │   └── ...
    └── utilities
        ├── meson.build
        └── ...

现在的挑战是编写介子构建文件来构建库和单元测试。单元测试显然取决于正在构建的库，在所有构建文件至少处理一次之前，我不会让库对象就绪。因此，我也无法在介子构建文件中定义测试可执行文件，因为我需要它们与库链接。

到目前为止，我已经想出了解决办法：

• 在根构建文件中定义lib_sources和test_sources列表，让所有子目录将源文件添加到这些列表中，然后在根构建文件中定义库和测试可执行文件。
• 让每个子目录创建自己的库并测试可执行文件。然后按照正确的顺序访问子目录以保留依赖关系(例如，先访问utilities，然后访问algorithms，然后访问containers)。稍后访问的子目录可以链接到早期子目录的库。并在根构建文件中创建一个组合所有子库的库。

我目前赞成第二种方法，因为每个子目录都定义了自己的目标，所以构建配置不是集中的。缺点是复杂性更高，我想。

如何理想地为这样的项目布局配置介子构建文件？

(注意:是的，我可以更改布局，并有单独的测试位置，但这违背了这种“挑战”的目的，即合并测试位置是必须的)。

Answer 1

你描述的第二个选择是我通常的做法。测试是在它们测试的库旁边的目录中定义的，比如，首先评估实用程序库。另一种选择是在定义了所有单个库之后，在src/<project>/meson.build中定义介子测试。

不过，在我看来，这是使用方便库(而不是安装中间静态库)的一个很好的理由。您可以将测试链接到这些库，并将这些库链接到最终的库中。如果最终的库可以共享，并且因此可能不会在内部公开所有可用的符号，这将是非常有用的。