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:

https://github.com/gnuradio/greps/blob/master/grep-0015-remove-swig.md


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

https://github.com/gnuradio/greps/pull/24

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:

https://github.com/mormj/gnuradio/tree/pybind11

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

<https://github.com/mormj/gnuradio/projects>

https://github.com/mormj/gnuradio/projects/1


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


Thanks!

Josh





Reply via email to