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 <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

diff --git a/bindings/python/bt2/setup.py.in b/bindings/python/bt2/setup.py.in
index d4e1ad23840342a5782e94e7c2ffc22f5e98deed..de4f0a014682e227aea7c97e92d1185c3061447a 100644 (file)
--- 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',