Distutils：构建多个共享一个方法的 Python 扩展模块（用 Swig 编写）

Question

我有四个 C++ 文件：Ah、A.cpp、Bh、B.cpp，Ah 包含在 B.cpp 中

啊：

#pragma once 
void A();

A.cpp：

#include <iostream>
void A() {
    std::cout << "A" << std::endl;
}

乙：

#pragma once
void B();

B.cpp：

#include "A.h"
#include <iostream>
void B() {
    A();
    std::cout << "B" << std::endl;
}

现在我写了两个 SWIG 接口文件 Ai 和 Bi

艾：

%module A
%{
#include "A.h"
%}
%include "A.h"

双：

%module B
%{
#include "B.h"
%}
%include "B.h"

setup.py 文件是：

from distutils.core import setup, Extension
A_ext = Extension( "_A", [ "A.i", "A.cpp", ], swig_opts = ['-c++'], extra_compile_args = ['-g'])
B_ext = Extension( "_B", [ "B.i", "B.cpp", ], swig_opts = ['-c++'], extra_compile_args = ['-g'])
setup(
    name = "test",
    version = "1.0",
    ext_modules = [ A_ext, B_ext ],
    py_modules = [ "A", "B" ]
)

如果我在下面输入命令，它会显示“A”。

python -c 'import A; A.A()' 

如果我在下面键入命令，则会出现分段错误：

python -c 'import B; B.B()'

我该怎么做才能正确运行此命令？ 由于我不想多次编译B.cpp，除了下面的方法之外还有其他方法吗？

B_ext = Extension( "_B", [ "B.i", "A.cpp", "B.cpp", ], swig_opts = ['-c++'], extra_compile_args = ['-g'])

Answer 1

为了清楚起见，我稍微更改了您的文件。

啊：

#pragma once 


void funcA();

a.cpp :

#include <iostream>


void funcA() {
    std::cout << __FILE__ << " " << __LINE__ <<  " " << __FUNCTION__ <<  std::endl;
}

艾：

%module a
%{
    #include "a.h"
%}
%include "a.h"

哈：

#pragma once


void funcB();

b.cpp :

#include "a.h"
#include <iostream>


void funcB() {
    std::cout << __FILE__ << " " << __LINE__ <<  " " << __FUNCTION__ <<  std::endl;
    funcA();
}

双:

%module b
%{
    #include "b.h"
%}
%include "b.h"

设置.py ：

from distutils.core import setup
from distutils.extension import Extension


a = "a"
b = "b"

ext_a = Extension("_" + a, [a + ".i", a + ".cpp"], swig_opts=("-c++",), extra_compile_args=["-g"])
ext_b = Extension("_" + b, [b + ".i", b + ".cpp"], swig_opts=("-c++",), extra_compile_args=["-g"])

setup(
    name="test",
    version="1.0",
    ext_modules=[ext_a, ext_b],
    py_modules=[a, b]
)

调用b.funcB时会发生什么（简化）（只有stacktrace ，导入被搁置一旁）。 每个步骤调用下一个：

1. funcB从模块B（b.py）
2. 从模块_b funcB（_b.so，或_b.cpython-35m-x86_64-linux-gnu.so）
   • 从这里开始的一切都发生在C （或C++ ）中
   • 当前funcB比从b.cpp的一个不同：它是由痛饮生成的，它的名字是_wrap_funcB
   • 上一个项目符号也适用于funcA和a.cpp
3. 从b.cpp funcB
4. FuncA的从a.cpp

问题是第 4步中的代码。 不在模块_b 中，它将在运行时失败。 但事情有点奇怪：调用funcB时不会出现故障（核心转储），而是在模块（ b -> _b ）导入时出现（我认为这是因为swig的幕后魔术），如见下。

输出：

 [cfati@cfati-ubtu16x64-0:~/Work/Dev/StackOverflow/q050938128]> ~/sopr.sh *** Set shorter prompt to better fit when pasted in StackOverflow (or other) pages *** [064bit prompt]> ls a.cpp ah ai b.cpp bh bi setup.py [064bit prompt]> python3 setup.py build > /dev/null 2>&1 [064bit prompt]> echo $? 0 [064bit prompt]> ls a.cpp ah ai a.py a_wrap.cpp b.cpp bh bi b.py build b_wrap.cpp setup.py [064bit prompt]> ls ./build/lib.linux-x86_64-3.5 _a.cpython-35m-x86_64-linux-gnu.so _b.cpython-35m-x86_64-linux-gnu.so [064bit prompt]> PYTHONPATH=${PYTHONPATH}:./build/lib.linux-x86_64-3.5 python3 -c "import _a;_a.funcA()" a.cpp 6 funcA [064bit prompt]> PYTHONPATH=${PYTHONPATH}:./build/lib.linux-x86_64-3.5 python3 -c "import _b" Segmentation fault (core dumped)

为了解决它，要么：

1. 正如您所指出的，在模块_b 中包含funcA （通过在ext_b的源文件列表中添加a.cpp ）。 这样一来，两个模块将是自包含的（从FuncA的的POV），每个将独立工作，也FuncA的将在他们两人被复制
2. 使_b依赖于_a （毕竟，它们是共享对象）。 但这不是Python扩展模块的使用方式，它不适用于Win （以及某些Nix风格）。 所以，这更像是一个（蹩脚的）解决方法（ Gainarie ）
3. 将a.cpp构建到两个模块都使用的不同共享库（一个.so ，但不是Python扩展模块）中。 不用说，在运行时，它们中的每一个都需要.so存在

显然，选项#3。 是完美的候选人。 但是distutils ( [Python.Docs]: API Reference ) 没有提供所需的功能OOTB （显然构建一个扩展模块和它依赖的外部共享库，这不是distutils 的目标场景），或者至少，我找不到任何。
有一个build_clib模块，它提供构建静态库的功能（由扩展模块使用），但这与选项#1相同。 .

设置.py ：

import sys
import os
from distutils.core import setup
from distutils.extension import Extension
from distutils.command.build_clib import build_clib
from distutils.command.build_ext import build_ext
from distutils.ccompiler import CCompiler


__win = sys.platform[:3].lower() == "win"
export_symbols_option = "export_symbols"


class build_clib_dyn(build_clib):
    def finalize_options(self):
        self.set_undefined_options('build',
                                   ('build_lib', 'build_clib'),
                                   ('build_temp', 'build_temp'),
                                   ('compiler', 'compiler'),
                                   ('debug', 'debug'),
                                   ('force', 'force'))
        self.libraries = self.distribution.libraries
        if self.libraries:
            self.check_library_list(self.libraries)
        if self.include_dirs is None:
            self.include_dirs = self.distribution.include_dirs or []
        if isinstance(self.include_dirs, str):
            self.include_dirs = self.include_dirs.split(os.pathsep)

    def build_libraries(self, libraries):
        for (lib_name, build_info) in libraries:
            sources = build_info.get('sources')
            if sources is None or not isinstance(sources, (list, tuple)):
                raise DistutilsSetupError(
                       "in 'libraries' option (library '%s'), "
                       "'sources' must be present and must be "
                       "a list of source filenames" % lib_name)
            sources = list(sources)
            macros = build_info.get('macros')
            include_dirs = build_info.get('include_dirs')
            objects = self.compiler.compile(sources,
                                            output_dir=self.build_temp,
                                            macros=macros,
                                            include_dirs=include_dirs,
                                            debug=self.debug)
            self.compiler.link(CCompiler.SHARED_OBJECT, objects, self.compiler.library_filename(lib_name, lib_type="shared"),
                               output_dir=self.build_clib,
                               export_symbols=build_info.get(export_symbols_option),
                               debug=self.debug)


if __win:
    class build_ext_w_dyn_dep(build_ext):
        def finalize_options(self):
            super(build_ext_w_dyn_dep, self).finalize_options()
            self.library_dirs.append(os.path.dirname(self.build_temp))

else:
    class build_ext_w_dyn_dep(build_ext):
        pass


a_name = "a"
b_name = "b"
common_name = a_name + b_name + "common"
swig_opts = ["-c++"]
libraries = [common_name]
lib_common_build_info = {"sources": [a_name + ".cpp"]}
if __win:
    extra_compile_args = None
    extra_link_args = None
    lib_common_build_info[export_symbols_option] = ["funcA"]
else:
    extra_compile_args = ["-g"]
    extra_link_args = ["-Wl,-rpath,${ORIGIN}"]

lib_common_info = (common_name, lib_common_build_info)
ext_a = Extension("_" + a_name, [a_name + ".i"], libraries=libraries, extra_compile_args=extra_compile_args, extra_link_args=extra_link_args, swig_opts=swig_opts)
ext_b = Extension("_" + b_name, [b_name + ".i", b_name + ".cpp"], libraries=libraries, extra_compile_args=extra_compile_args, extra_link_args=extra_link_args, swig_opts=swig_opts)

setup(
    name="test",
    version="1.0",
    libraries=[lib_common_info],
    cmdclass={"build_clib": build_clib_dyn, "build_ext": build_ext_w_dyn_dep},
    ext_modules=[ext_a, ext_b],
    py_modules=[a_name, b_name]
)

注意事项：

• build_clib_dyn扩展了build_clib，因为它的功能必须被修改。 覆盖了 2 个方法，但只有其中的一小部分实际发生了变化（注释没有从基类方法（ Python 3.5.4代码库）中复制，以减少代码量，但这并不算真正的变化）
• 该任务需要浏览一些distutils代码，因为某些选项没有记录（而且我对它不是很熟悉）
• 还需要一些Nix知识，因为在加载不在系统路径中的共享库时事情会变得棘手，并且还需要保持顺畅（例如不改变${LD_LIBRARY_PATH} ）
• build_ext_w_dyn_dep类似于build_clib_dyn （仅限Win ）。 由于在构建Win动态链接库 ( .dll ) 时，会生成 2 个文件，并且在这种情况下它们不在同一个目录中，因此需要对库搜索路径进行一些调整
• Python 3和Python 2兼容

输出（再次运行上述命令）：

 [064bit prompt]> ls a.cpp ah ai b.cpp bh bi setup.py [064bit prompt]> python3 setup.py build > /dev/null 2>&1 [064bit prompt]> echo $? 0 [064bit prompt]> ls a.cpp ah ai a.py a_wrap.cpp b.cpp bh bi b.py build b_wrap.cpp setup.py [064bit prompt]> ls build/lib.linux-x86_64-3.5/ _a.cpython-35m-x86_64-linux-gnu.so _b.cpython-35m-x86_64-linux-gnu.so libabcommon.so [064bit prompt]> ldd build/lib.linux-x86_64-3.5/_a.cpython-35m-x86_64-linux-gnu.so linux-vdso.so.1 => (0x00007fffadb49000) libabcommon.so => /home/cfati/Work/Dev/StackOverflow/q050938128/build/lib.linux-x86_64-3.5/libabcommon.so (0x00007f91cd50f000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f91cd18d000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f91ccf77000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f91ccbad000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f91cc990000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f91cc687000) /lib64/ld-linux-x86-64.so.2 (0x00007f91cd916000) [064bit prompt]> PYTHONPATH=${PYTHONPATH}:./build/lib.linux-x86_64-3.5 python3 -c "import _a;_a.funcA()" a.cpp 6 funcA [064bit prompt]> PYTHONPATH=${PYTHONPATH}:./build/lib.linux-x86_64-3.5 python3 -c "import _b;_b.funcB()" b.cpp 7 funcB a.cpp 6 funcA

• 添加了对Win 的支持（我想，这对问题不是很重要）
  • 由于模块结构很简单，因此可以在setup.py级别执行所有操作（不必修改源文件）
  • 唯一的额外要求是swig.exe的目录应该在%PATH%