> On Feb. 23, 2017, 9:37 p.m., Tony Gutierrez wrote: > > This seems like a welcome change. A question: are there any requirements > > for using PyBind besides Python 2.7 or 3.x and the std clibs? I see that > > the PyBind GitHub only mentions these dependencies, and I wanted to get > > confirmation based on your experiences using it.
There shouldn't be any external dependencies other than Python 2.7/3.x and C++11. I have tested it with gcc 4.8 our CI system (RHEL 6.6), gcc 6.2, and clang 3.8. I haven't seen any issues other than a weird clang error (possibly a clang bug) related to the PyEventDeleter class. I have updated the patch to work around that issue. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3827/#review9469 ----------------------------------------------------------- On Feb. 24, 2017, 10:20 a.m., Andreas Sandberg wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3827/ > ----------------------------------------------------------- > > (Updated Feb. 24, 2017, 10:20 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11884:e0f1c63a8440 > --------------------------- > python: Use PyBind11 instead of SWIG for Python wrappers > > Use the PyBind11 wrapping infrastructure instead of SWIG to generate > wrappers for functionality that needs to be exported to Python. This > has several benefits: > > * PyBind11 can be redistributed with gem5, which means that we have > full control of the version used. This avoid a large number of > hard-to-debug SWIG issues we have seen in the past. > > * PyBind11 doesn't rely on a custom C++ parser, instead it relies on > wrappers being explicitly declared in C++. The leads to slightly > more boiler-plate code in manually created wrappers, but doesn't > doesn't increase the overall code size. A big benefit is that this > avoids strange compilation errors when SWIG doesn't understand > modern language features. > > * Unlike SWIG, there is no risk that the wrapper code incorporates > incorrect type casts (this has happened on numerous occasions in > the past) since these will result in compile-time errors. > > As a part of this change, the mechanism to define exported methods has > been redesigned slightly. New methods can be exported either by > declaring them in the SimObject declaration and decorating them with > the cxxMethod decorator or by adding an instance of > PyBindMethod/PyBindProperty to the cxx_exports class variable. The > decorator has the added benefit of making it possible to add a > docstring and naming the method's parameters. > > The new wrappers has the following known issues: > > * Global events can't be memory managed correctly. This was the > case in SWIG as well. > > Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763 > Signed-off-by: Andreas Sandberg <andreas.sandb...@arm.com> > Reviewed-by: Andreas Hansson <andreas.hans...@arm.com> > Reviewed-by: Andrew Bardsley <andrew.bards...@arm.com> > > > Diffs > ----- > > src/cpu/BaseCPU.py ba90ffa751b6 > src/arch/arm/ArmPMU.py ba90ffa751b6 > src/SConscript ba90ffa751b6 > src/python/pybind11/stats.cc PRE-CREATION > src/python/swig/core.i ba90ffa751b6 > src/python/swig/debug.i ba90ffa751b6 > src/python/swig/drain.i ba90ffa751b6 > src/python/swig/event.i ba90ffa751b6 > src/python/swig/inet.i ba90ffa751b6 > src/python/swig/pyevent.hh ba90ffa751b6 > src/python/swig/pyevent.cc ba90ffa751b6 > src/python/swig/pyobject.hh ba90ffa751b6 > src/python/swig/pyobject.cc ba90ffa751b6 > src/python/swig/pyobject.i ba90ffa751b6 > src/python/swig/range.i ba90ffa751b6 > src/python/swig/serialize.i ba90ffa751b6 > src/python/swig/stats.i ba90ffa751b6 > src/python/swig/time.i ba90ffa751b6 > src/python/swig/trace.i ba90ffa751b6 > src/sim/Process.py ba90ffa751b6 > src/sim/System.py ba90ffa751b6 > src/sim/init.hh ba90ffa751b6 > src/sim/init.cc ba90ffa751b6 > src/sim/power/PowerModel.py ba90ffa751b6 > src/sim/power/PowerModelState.py ba90ffa751b6 > src/sim/power/ThermalDomain.py ba90ffa751b6 > src/sim/power/ThermalModel.py ba90ffa751b6 > src/unittest/SConscript ba90ffa751b6 > src/unittest/stattest.cc ba90ffa751b6 > src/unittest/stattest.i ba90ffa751b6 > tests/configs/switcheroo.py ba90ffa751b6 > src/cpu/kvm/BaseKvmCPU.py ba90ffa751b6 > src/cpu/kvm/X86KvmCPU.py ba90ffa751b6 > src/python/SConscript ba90ffa751b6 > src/python/_m5/__init__.py ba90ffa751b6 > src/python/m5/SimObject.py ba90ffa751b6 > src/python/m5/event.py ba90ffa751b6 > src/python/m5/internal/params.py ba90ffa751b6 > src/python/m5/params.py ba90ffa751b6 > src/python/m5/util/pybind.py PRE-CREATION > src/python/pybind11/core.cc PRE-CREATION > src/python/pybind11/debug.cc PRE-CREATION > src/python/pybind11/event.cc PRE-CREATION > src/python/pybind11/pybind.hh PRE-CREATION > src/python/pybind11/pyobject.cc PRE-CREATION > SConstruct ba90ffa751b6 > src/arch/arm/ArmSystem.py ba90ffa751b6 > > Diff: http://reviews.gem5.org/r/3827/diff/ > > > Testing > ------- > > NOTE: I have few cleanup patches that remove SWIG-related stuff from the > build system and the C++ files. These will be submitted separately if this > gets approved. > > > Thanks, > > Andreas Sandberg > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
