构建结构
要生成gtkmm风格的API封装源代码需要使用包含在glibmm的工具，例如gmmproc和generate_wrap_init.pl。理论上来说你可以自己编写构建文本以更好的使用它们，不过更好的选择是利用mm-common模块提供的构建基础设施。选择一个已经存在绑定的模块作为示例对于开始使用gmmproc很有帮助。
假设，我们封装了一个名为libsomething的C库。它提供了基于GObject API的具名类型，例如类型名为：SomeWidget和SomeStuff。
- G.1.1. 复制skeleton项目
- G.1.2. 修改构建文件
G.1.1. 复制skeleton项目
我们封装的库名为libsomethingmm。我们可以从在mm-common模块中复制skeleton源代码树开始。自mm-common 1.0.0开始skeleton应用程序使用Meson构建系统进行构建。
$ git clone https://gitlab.gnome.org/GNOME/mm-common.git $ cp -a mm-common/skeletonmm libsomethingmm
这为源.hg和.ccg文件、手写的.h和.cc文件提供了目录结构，meson.build文件可以通过各种变量指定Meson使用哪些文件进行编译。适当的重命名目录后，目录结构将如下所示：
-
libsomethingmm：顶级目录。
-
libsomething：包含主要的被包含文件(被#include的文件)和由pkg-config所需的.pc文件。
- src：包含.hg和.ccg源文件。
- libsomethingmm：包含手写的.h和.cc文件。
-
除了重命名目录外，我们还应该重命名一些源文件。例如：
$ for f in $(find libsomethingmm -depth -name '*skeleton*'); do \
d="${f%/*}"; b="${f##*/}"; mv "$f" "$d/${b//skeleton/libsomething}"; \
done
请注意，在配置阶段中某些变量将会替换为实际值，这将会生成与.in相同名称但不带.in后缀的文件。
生成的文件被保存在构建树中，当使用meson和ninja时构建树会与源树分离。
G.1.2. 修改构建文件
现在我们修改构建文件以适应我们的需求。在这个时候你可能喜欢使用类似于regexxer这样的多文件搜索替换工具。请注意，skeleton源代码树提供的所有文件几乎都包含了占位符。因此，应该进行全局替换而不是仅对Meson文件替换。
所有提到skeleton的地方都应该替换成你想要封装的C库的名称，例如替换成"something"或"libsomething"。同样的，所有的SKELETON都应该被替换成"SOMETHING"或"LIBSOMETHING"，以及所有的Skeleton都应该被替换为"Something"。
同样的，将所有的Joe Hacker替换为预期的版权所有者的名称，也就是你的名称。然后对joe@example.com邮件地址进行同样的操作。
- G.1.2.1. 顶级目录中的meson.build
- G.1.2.2. 其他meson.build文件
- G.1.2.3. 创建.hg个.ccg文件
G.1.2.1. 顶级目录中的meson.build
- 使绑定模块的版本跟踪被封装的库的版本很常见。例如，C库版本是1.23.4，则绑定模块的初始版本为1.23.0。但是请尽量避免以偶数次要版本开始，因为这通常意味着该版本是稳定版本。
- 如果有必要，请在project()函数中修改许可证和C++版本。
- 你可能需要添加除glibmm和skeleton(libsomething)以外的必需模块。
G.1.2.2. 其他meson.build文件
接下来我们必须对其他的meson.build文件进行修改：
-
skeleton/meson.build：在这除了全局替换以外基本上不需要做什么。
-
skeleton/skeletonmm/meson.build
- defs_basefiles
在这添加额外的.defs和docs.xml文件
- hg_ccg_basenames
必须在这里提及所有的.hg和.ccg。
- extra_cc_files, extra_h_files
所有手写的.h和.cc源文件都需要写在这。
G.1.2.3. 创建.hg个.ccg文件
现在我们应该创建第一个.hg和.ccg，用以对一个C库中的对象进行封装。存在一对可供参考的示例源文件：skeleton.ccg和skeleton.hg。请根据需要创建这些文件的副本。
在.hg和.ccg文件小节你可以学到这些文件使用的语法。