Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code

[Håkon Vågsether]

Hi Ben,

thank you for your comments.

On Wed, Mar 29, 2017 at 6:33 PM, Ben Hilburn <address@hidden> wrote:

Hi Håkon -

Hah, indeed, your update and my e-mail flew past each other. I just took a read over your update, and have some further comments:

• I see you added some design details about Cheetah. So, actually, we are in the process of migrating to Mako. You probably didn't see this because the work is taking place in the 3.8.x development, and is not reflected in the current 3.7.x branches.

Right! Thanks for pointing that out, I've been using the master branch until you made me aware of this. I noticed the code generation part is still in Cheetah, I suppose I can help out with porting to Mako?

• I think details of how you will integrate the need to compile C++ flowgraphs into the GRC UX will be important to call out in the proposal.

I've attempted to create a mock-up of how I think it could look:
​

 dropdown.png

​

Here "Compile" has been greyed out because Python is selected. "Options" brings up a new dialog window with more build options. This is not a very drastic change from the current state of the program, and I doubt it will confuse people who aren't used to the new options. Might want to change "Run" to "Build" and "Language" to "Output" or something like that, but this might not be as important at this stage.

• One of the major complexities, here, is that there are a lot of blocks that are Python-only. How will you deal with blocks that don't have C++ implementations?

Yes I see. I imagine for the time being the UI will have to give an error and refuse to switch to C++ output if there are Python-only blocks present in the flowgraph. For example, gui/NotebookPage.py could have a check_cpp_compatible() method that is called from gui/ActionHandler.py when the user tries to switch to C++ output. I suppose this method would then have to check if there are any of the blocks in the flowgraph that aren't in a list of successfully ported blocks. There's probably a more elegant way to do this, just a suggestion :)

Best regards,

Håkon Vågsether