scons: Track swig packages when loading embedded swig code

Information
Submitter:	Andreas Hansson
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 11519:3a81d85e6eff
---------------------------
scons: Track swig packages when loading embedded swig code

This patch changes how the embedded swig code is loaded to ensure that
gem5 works with swig 3.0.9. For Python 2.7 and above, swig 3.0.9 now
relies on importlib, and actually looks in the appropriate packages,
even for the wrapped C code. However, the swig wrapper does not
explicitly place the module in the right package (it just calls
Py_InitModule), and we have to take explicit action to ensure that the
swig code can be loaded. This patch adds the information to the
generated wrappers and the appropriate calls to set the context as
part of the swig initialisation.

Previous versions of swig used to fall back on looking in the global
namespace for the wrappers (and still do for Python 2.6), but
technically things should not work without the functionality in this
patch.

Testing Done

Issue Summary

Description	From	Last Updated	Status
FYI: this is exactly what happens in cpython/Python/importdl.c.	Nathan Binkert	June 14, 2016, 1:27 p.m.	Dropped
make_unique<char[]> ?	Nathan Binkert	June 14, 2016, 1:27 p.m.	Dropped

Any input?

src/sim/init.cc (Diff revision 1)

FYI: this is exactly what happens in cpython/Python/importdl.c.

Show all issues

src/sim/init.cc (Diff revision 1)

make_unique<char[]> ?

Show all issues

Andreas Hansson June 14, 2016, 1:27 p.m. (June 14, 2016, 1:27 p.m.)
```
c++11, not c++14 yet :-)
```
Nathan Binkert June 14, 2016, 1:36 p.m. (June 14, 2016, 1:36 p.m.)
```
https://github.com/binkert/make_unique
```

Nathan Binkert June 14, 2016, 1:45 p.m. (June 14, 2016, 1:45 p.m.)

vector<char> also works well in this case. Anyway, it doesn't matter that much.

The official standardese version is available here:
https://isocpp.org/files/papers/N3656.txt

Mine added T[N] as a valid option which the standard didn't like.

Looks reasonable to me. There's even a whole comment in modsupport.c about this:
/* Make sure name is fully qualified.

   This is a bit of a hack: when the shared library is loaded,
   the module name is "package.module", but the module calls
   Py_InitModule*() with just "module" for the name.  The shared
   library loader squirrels away the true name of the module in
   _Py_PackageContext, and Py_InitModule*() will substitute this
   (if the name actually matches).
*/

Also, there's a discussion with Guido here. https://mail.python.org/pipermail/python-dev/2002-August/028075.html

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Issue Summary

Status: Closed (submitted)