我对介子专家有点挑战。
我最新的C++项目(一个库(是根据Pitchfork布局构建的。在这个约定允许的情况下，我决定使用合并的头和合并的测试位置。这基本上意味着我的头文件、源文件和测试源文件都是同一个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(。随后访问的子目录可以链接到先前子目录的库。并且在根构建文件中创建一个合并所有子库的单个库
我目前赞成第二种方法，因为每个子目录都定义了自己的目标，所以构建配置不是集中的。我想缺点是复杂性更高。
对于这样的项目布局，我应该如何理想地配置介子构建文件
(注意：是的，我可以更改布局并进行单独的测试布局，但这违背了合并测试布局是必备的"挑战"的目的(
您描述的第二个选项是我通常的方法。测试是在他们测试的库旁边的目录中定义的，首先评估实用程序库之类的东西。另一种选择是在定义了所有单独的库之后，在src/<project>/meson.build中定义介子测试。
不过，在我看来，这是使用便利库(而不是安装中间静态库(的一个很好的理由。您可以将测试与这些库链接，并将这些库链接到最终库中。如果最终库可以共享，并且因此可能不会公开内部可用的所有符号，那么这将非常有用。