大约两年前,当我第一次实现SWIG绑定时,我遇到了这个问题.一旦我们暴露了大量的代码,我们就到了SWIG输出C++文件这么大的程度,编译器无法处理它们.解决这个问题的唯一方法是将接口拆分为多个模块并单独编译.
这有几个缺点:
•每个模块必须知道其他模块中的依赖关系.我有一个脚本来生成处理这方面的接口文件,但它增加了额外的复杂性.
•每个附加模块都会增加动态链接器加载代码所需的时间.我添加了一个导入所有子模块的init .py文件,因此代码被拆分的事实对用户来说是透明的,但总是可见的是加载时间长.
我目前正在审查我们的构建脚本/构建过程,我想看看我能否找到一个比我现在更好的问题的解决方案.理想情况下,我有一个包含所有包装器代码的共享库.
有谁知道如何用SWIG实现这一目标？我已经看到一些用Ruby编写的自定义代码用于特定项目,其中输出经过后处理以实现这一点,但是当我查看Python包装器的可行性时,它看起来并不那么容易.
如果正确分割，模块不一定需要与其他模块具有相同的依赖关系 - 只是进行编译所必需的。如果你适当地分解事情，你就可以拥有没有循环依赖的库。使用多个库的问题是，默认情况下，SWIG 静态声明其运行时代码，因此，将对象从一个模块传递到另一个模块时会出现问题。您需要启用 SWIG 运行时代码的共享版本。
从文档（SWIG 网页文档链接已损坏）：
运行时函数是每个 SWIG 生成的模块私有的。也就是说，运行时函数是用“静态”链接声明的，并且仅对该模块中定义的包装器函数可见。这种方法的唯一问题是，当同一应用程序中使用多个 SWIG 模块时，这些模块通常需要共享类型信息。对于 C++ 程序尤其如此，其中 SWIG 必须收集和共享有关跨模块边界的继承关系的信息。
查看下载文档中的该部分（第 16.2 节 SWIG 运行时代码），它将为您提供有关如何启用此功能的详细信息，以便在将对象从一个模块传递到另一个模块时可以正确处理对象。
FWIW，我没有使用过 Python SWIG，但使用过 Tcl SWIG。