[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU Radio Transition from SWIG to pybind11 - looking for community invol

From: Morman, Joshua
Subject: GNU Radio Transition from SWIG to pybind11 - looking for community involvement
Date: Fri, 21 Feb 2020 16:49:32 +0000

Hi All,

As was discussed on the project call yesterday, we are in the process of migrating away from SWIG for binding the C++ API into python.  This brings the following advantages:

- One less giant dependency

- Faster/less memory usage during compile

- Less cryptic auto-generated code

- More deliberate binding of the API

There are of course tradeoffs, and one of the downsides of moving away from SWIG, is that SWIG mostly automates the step of C++ header to compiled binding code conversion.  Both Boost.python and pybind11 require bindings to be written manually - it is this workflow where we need to focus effort so creating these bindings is as seamless as possible. 

What I'm seeking involvement from the community is for is the following:

1) Feedback on the general approach

-  We should be having discussion about larger features such as these using the GREP (GNU Radio Enhancement Process) mechanism, which lives in github, for this specific feature as GREP0015:


More updated information about the current approach is proposed in this pull request:


So, feel free to comment, suggest ideas, concerns directly on the pull request (or via the mailing list if you are so inclined)

2) Tools for automating the workflow

- The current approach follows the pyuhd code structure and leverages the block header parsing tool developed by Arpit G. as a GSoC project for generating the binding code

- Needs further integration into modtool, cmake, whatever other mechanisms make for a smooth experience

- Especially needs to be as little overhead as possible for OOT transitions to the new mechanism

3) Building out GR module tree and updating OOTs (once key design decisions are solidified)

- I have pushed forward with making binding code for some of the larger modules

- Mainly to determine feasibility, and find gotchas - there are definitely improvements in compile time and memory utilization

- But it will be important to build out these bindings using the tools developed in (2)

The current work effort lives on my fork - pybind11 branch:


And I have tried to track progress, issues and improvement opportunities here:


If you are interested in getting involved in this effort, please email me back here, or on slack @mormj



reply via email to

[Prev in Thread] Current Thread [Next in Thread]