summary |
shortlog |
log |
commit | commitdiff |
tree
raw |
patch |
inline | side by side (from parent 1:
73485cf)
In SWIG 3, the native module (`_native_bt.*.so`, which they call the
"C/C++ module") can be found in two locations by the Python module
(`native_bt.py`). From
http://www.swig.org/Doc3.0/SWIGDocumentation.html#Python_package_search:
> The pure Python module needs to load the C/C++ module in order to link
> to the wrapped C/C++ methods. To do this it must make some assumptions
> about what package the C/C++ module may be located in. The approach
> the pure Python module uses to find the C/C++ module is as follows:
>
> 1. The pure Python module, foo.py, tries to load the C/C++ module,
> _foo, from the same package foo.py is located in. The package name
> is determined from the __name__ attribute given to foo.py by the
> Python loader that imported foo.py. If foo.py is not in a package
> then _foo is loaded as a global module.
>
> 2. If the above import of _foo results in an ImportError being thrown,
> then foo.py makes a final attempt to load _foo as a global module.
In other words, `native_bt.py` tries:
from . import _native_bt
If this fails:
import _native_bt
Currently, we're using the second location (global module).
In SWIG 4.0.0, released 27 april 2019, things changed. From
http://www.swig.org/Doc4.0/SWIGDocumentation.html#Python_package_search:
> The pure Python module needs to load the C/C++ module in order to call
> the wrapped C/C++ methods. To do this it must make some assumptions
> about the location of the C/C++ module. There are two configurations
> that are supported by default.
>
> 1. Both modules in the same package
>
> 2. Both modules are global
and:
> Compatibility Note: Versions of SWIG prior to SWIG-4.0.0 supported
> split modules without the above customization. However, this had to be
> removed as the default import code often led to confusion due to
> obfuscation of genuine Python ImportError problems. Using one of the
> two default configurations is the recommended approach now.
In other words, `native_bt.py` does not try
import _native_bt
because `native_bt.py` is part of a package; it only tries:
from . import _native_bt
The result is that, when the bindings are generated by SWIG 4,
`native_bt.py` cannot find `_native_bt`, which makes the bindings not
work at all.
The common method for SWIG 3 and 4 is importing from the same package.
For this to work, `setup.py` needs to install the built extension into
the `bt2` package. This patch changes `bindings/python/bt2/setup.py.in`
to do so.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Icf3622953280466e8d458caee79a28ed4a01fa2b
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1356
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins
- babeltrace_ext = Extension('_native_bt',
+ babeltrace_ext = Extension('bt2._native_bt',
sources=['bt2/native_bt.i', 'bt2/logging.c'],
libraries=['babeltrace', 'glib-2.0'],
extra_objects=['@top_builddir@/logging/.libs/libbabeltrace-logging.a',
sources=['bt2/native_bt.i', 'bt2/logging.c'],
libraries=['babeltrace', 'glib-2.0'],
extra_objects=['@top_builddir@/logging/.libs/libbabeltrace-logging.a',