From 877cb1e2f9ca0f090b474f06e6fc593cce61331f Mon Sep 17 00:00:00 2001 From: Philippe Proulx Date: Fri, 31 May 2019 07:07:04 -0400 Subject: [PATCH] bindings/python/bt2/setup.py.in: put native module in `bt2` package 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 Change-Id: Icf3622953280466e8d458caee79a28ed4a01fa2b Reviewed-on: https://review.lttng.org/c/babeltrace/+/1356 Reviewed-by: Simon Marchi Tested-by: jenkins --- bindings/python/bt2/setup.py.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bindings/python/bt2/setup.py.in b/bindings/python/bt2/setup.py.in index d4e1ad23..de4f0a01 100644 --- a/bindings/python/bt2/setup.py.in +++ b/bindings/python/bt2/setup.py.in @@ -35,7 +35,7 @@ following command to your .bashrc/.zshrc: """ def main(): - 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', -- 2.34.1