Specify which methods show up in SWIG version of C++ block

GNU Radio
1

I’m working on some custom C++ blocks. I would like to have a few
methods in the C++ world visible to Python so that they can be called
directly. My understanding is that GRC can then make such things
visible through the tag in the block’s XML specification.

Looking at the GR3.7 version of fir_filter, for instance, shows that
it has a “set_taps” method and an “update_tap” method, both of which
are public. However, only “set_taps” gets translated into the SWIG
Python version of the fir_filter block, while “update_tap” does not.
What part of the gr-filter source tree instructs SWIG to include one
but not the other? Does it have something to do with the way the
GR_SWIG_BLOCK_MAGIC2() macro works within filter_swig.i?

Short version: how do I instruct the SWIG build process to translate a
particular method of a C++ GR block into its Python version?

Thanks in advance.

Ethan

2

When you create a block with gr_modtool your implementation goes in the
lib/[block_name]_impl.[h|cc] files. However, the swig procedures look at
the include/[package_name]/[block_name].h files to determine which
methods
to expose in the generated python class. So, to make a C++ method
available
in the python class, create a virtual method in the
include/[package_name]/[block_name].h and implement it in the
lib/[block_name]_impl.[cc|h] subclass.

3

Declare a pure virtual function in (for example)
gr-OOT/include/OOT/myblock.h :

virtual int how_many_things(const int n) const = 0;

Then declare a concrete function in gr-OOT/lib/myblock_impl.h :

int how_many_things(const int n) const;

Then define your concrete function in gr-OOT/lib/myblock_impl.cc :

int how_many_things(const int n)
{
return n;
}

If you added your block with gr_modtool, you’ll find this in
gr-OOT/swig/OOT_swig.i :

%{
…
#include “OOT/myblock.h”
…
%}
…
%include “OOT/myblock.h”
…
GR_SWIG_BLOCK_MAGIC2(OOT, myblock);

The above statements will automagically SWIG anything defined in
myblock.h.