Re: Adding C++ Code generation support for c++ implemented blocks

[Marcus Müller]

Hey Martin,

welcome to the community :)
As you can imagine, with the GNU Radio project, code contributions are always welcome, 
especially when it comes to adding code generation for existing blocks written in C++. I'm 
pretty optimistic Daniel feels the same way about gr-satellites.

The S-NET flowgraph screenshot is already a bit older, it still uses GNU Radio 3.7, but 
with the symbol sync block, it might be quite straightforward to port it (Clock Recovery 
MM has been deprecated; you can use Symbol Sync with a Mueller and Müller TED instead). 
You need modern GNU Radio, because on 3.7, C++ generation was not there, and also, the 
more modern the GNU Radio, the more blocks already come with C++ generation definitions.

I do have one piece of bad news for you, though: Many (most, I think) blocks in 
gr-satellites, such as the S-NET deframer, are Python blocks. So, the thing that's missing 
for creating C++ flowgraphs out of these is not only the definition of how the C++ code 
needed to instantiate them looks like, but also: a C++ implementation!

And that is where it gets hairy: I don't think it's overly complicated to re-implement 
snet_deframer.py from gr-satellites in C++. The question is whether you *should*, on two 
levels: first, that's an effort you'd be doing to recreate something that already exists, 
and second, you should probably really work with upstream (so, Daniel) on whether he would 
prefer your C++ implementation (he positively might! It's going to faster, especially 
since you'll be implementing the BCH decodder in C++) or his Python implementation (which 
is going to be easier to read and maintain, probably). The thing with upstreaming is that 
you're giving someone your code to take care of, and that's a bit like giving away free 
puppies: A great gesture, but comes with some work.

In this light, I'd recommend you go through each block in the flowgraphs / applications 
you want to use and consider whether it's worth going through the porting effort to avoid 
having to package Python.

There's an alternative to having to package Python yourself, and all the libraries (which 
are quite a few) that (the used subset of the in-tree modules of) GNU Radio + 
gr-satellites would use:
Make sure the conda recipes work flawlessly for the software you want to ship, and build a 
conda installer akin to Ryan's radioconda for that specific application. I guess you're 
mostly targeting Windows there – making a nice installer should not be impossible, but I 
don't have any personal experience with it. That would have the added benefit that, if you 
decide that you want your target audience to also have access to truly unportable 
Python-only software like GRC, you could, at nearly no development cost, add that.

Either way, what you set out to do is truly remarkable and I'm happy you're 
tackling it!

Best,
Marcus


On 18.05.23 11:25, Martin Hübner wrote:

> Similarily, the C++ support for the rather easy quadrature demod block should look like 
> this then, right?
> https://github.com/Akira25/gnuradio/tree/add\_cpp\_generation-quadmod

That link's private, but if you want us to have a look at it, why don't you open a pull 
request against gnuradio/gnuradio? You can mark it as "Draft" and write a nice comment 
what it signifies, and maybe even link to your message in the discuss-gnuradio mailing 
list archives.