c – 是否可以拆分SWIG模块进行编译,但在链接时重新加入？

大约两年前,当我第一次实现SWIG绑定时,我遇到了这个问题.一旦我们暴露了大量代码,我们就会发现SWIG输出的C文件太大,编译器无法处理它们.解决这个问题的唯一方法是将接口拆分为多个模块并单独编译.

这有几个缺点：

•每个模块必须知道其他模块中的依赖关系.我有一个脚本来生成处理这方面的接口文件,但它增加了额外的复杂性.

•每个附加模块都会增加动态链接器加载代码所需的时间.我添加了一个导入所有子模块的init.py文件,因此拆分代码的事实对用户来说是透明的,但总是可见的是加载时间长.

我目前正在审查我们的构建脚本/构建过程,我想看看我能否找到一个比我现在更好的问题的解决方案.理想情况下,我有一个包含所有包装器代码的共享库.

有谁知道如何用SWIG实现这一目标？我已经看到一些用Ruby编写的自定义代码用于特定项目,其中输出经过后处理以实现这一点,但是当我查看Python包装器的可行性时,它看起来并不那么容易.

解决方法

如果正确拆分,模块不一定需要具有与其他模块相同的依赖关系 – 只需要进行编译即可.如果你适当地分解,你可以拥有没有循环依赖的库.使用多个库的问题是,默认情况下,SWIG静态地声明其运行时代码,因此,将对象从一个模块传递到另一个模块时出现问题.您需要启用SWIG运行时代码的共享版本.

从文档(SWIG网页文档链接中断)：

The runtime functions are private to
each SWIG-generated module. That is,
the runtime functions are declared
with “static” linkage and are visible
only to the wrapper functions defined
in that module. The only problem with
this approach is that when more than
one SWIG module is used in the same
application,those modules often need
to share type information. This is
especially true for C++ programs where
SWIG must collect and share
information about inheritance
relationships that cross module
boundaries.

查看下载文档中的该部分(第16.2节SWIG运行时代码),它将为您提供有关如何启用此功能的详细信息,以便在从一个模块传递到另一个模块时可以正确处理对象.

FWIW,我没有使用过Python SWIG,但已经完成了Tcl SWIG.

原文地址：https://www.jb51.cc/c/117519.html