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

[Martin Braun]

There's another thing: On 3.8, we'll be going to a different model of
writing GRC bindings (YAML-based). It's difficult to summarize the
changes, but basically, don't assume that we'll be using XML files forever.

-- M

On 03/29/2017 08:52 AM, Ben Hilburn wrote:
> Hi Håkon -
> 
> Welcome! I'm really excited to see someone tackling C++ Code Generation.
> As Marcus said, it's something that people have been asked about for
> years, and it would be great to get it implemented. A few questions /
> suggestions on your proposal:
> 
>   * As Marcus mentioned, simple proposals are great, but I do think you
>     need a bit more detail. Marcus covered this well in his e-mail, so I
>     won't add anything to that point.
>   * This is the sort of functionality that would be best upstreamed
>     rather than existing in an OOT module. We should discuss how this
>     process might work, as it requires a CLA to the FSF. If you aren't
>     familiar with this, please e-mail me & Johnathan
>     (address@hidden <mailto:address@hidden>) so that we can
>     describe it further.
>   * One of the big differences between generating Python and generating
>     C++ is that a C++ flowgraph will need to be compiled before being
>     executed. Laying out how you plan to handle that flow from GRC, I
>     think, will be really important.
> 
> Again, welcome, and I look forward to seeing where this work goes =)
> 
> Cheers,
> Ben
> 
> On Sun, Mar 26, 2017 at 10:48 AM, Marcus Müller
> <address@hidden <mailto:address@hidden>> wrote:
> 
>     Dear Håkon,
> 
>     cool! The C++ output option for GRC has been on many wishlists for a
>     long long time.
> 
>     I do like the brevity of your proposal, however I miss a bit of you
>     describing /how/ exactly you want to do things, and what to focus on
>     in which order. We're well aware of this specific idea being
>     displayed very generally in the ideas list; that has the purpose of
>     letting you pick and discuss your focus very freely. If I understand
>     your timeline properly, your order of things is
> 
>      1. Add GUI elements to GRC to make it to connect functionality later
>      2. C++ code generator
>      3. Build system infrastructure
> 
>     Having the UI interface as first item seems like a positive approach
>     to get to know the Python code of GRC a little better. I do think it
>     kind of could wait until you'd actually be able to generate C++ code
>     – that'd give you the chance to get a lot of feedback early and
>     change directions of how you do things; GRC in it's current
>     situation is relatively well split between the GUI and the (Python)
>     code generation.
> 
>     I assume you've had a rough look at how Python generation in GRC
>     works right now (block_name.xml files describe the GRC blocks,
>     including the code that has to be called to instantiate an instance
>     of the GNU Radio block class, and how these blocks are set up and
>     connected is described in flow_graph.grc files; the actual python
>     code is a template filled with the info from these).
> 
>     Now, in a first approach, this would "only" (as if) be a matter of
>     adding new templates for the generated code, and new tags to the
>     .xml files that describe which C++ code to call – but it would still
>     be great to see you reflect a bit on whether you deem the same
>     (Python-generation) templating infrastructure suitable for this use
>     case (really, doesn't have to be in-depth – this is just a proposal)
>     or whether you'd think there's things to change.
> 
>     Same goes for the "Makefile" generation. We really won't nail you
>     down on what you propose now, but you giving a vision (maybe in a
>     quick block diagram) of how the Makefile (or build system, in
>     general – we use CMake in GNU Radio, and if you'd have another idea
>     how to generate an executable from the C++ you generate, don't be
>     shy, we can and will gently criticize if we found that necessary ;)
>     ) will come together, and give maybe a list of infos on what info
>     comes from where and ends up in the C++ header and the main source
>     file and the Makefile, it'd give me a fuzzy warm feeling about you
>     having a plan how to approach things.
> 
>     So: I like your project proposal, but I like it so much that I'd
>     want to see more of a proposed idea here. I think both Felix and
>     Sebastian don't want to mentor you as a "code monkey" – the whole
>     project would very much value you as active critic and architect of
>     "how things are done" in GRC and GNU Radio in general, so it's kind
>     of important to us that you emphasize how your plan is more than
>     what the Idea from the GSoC Ideas List already defines.
> 
>     Best regards,
> 
>     Marcus
> 
>     On 03/26/2017 02:20 PM, Håkon Vågsether wrote:
>>     Hello!
>>
>>     My name is Håkon Vågsether, and I am a first year MSc student in
>>     Cybernetics and Robotics at NTNU's (Norwegian University of
>>     Science and Technology, Trondheim). I am very interested in
>>     participating in GSoC 2017 for GNU Radio and I have added a link
>>     below to my proposal draft for the GRC C++ output idea for this
>>     year's GSoC. I believe I have added everything that was required,
>>     but I suppose I will have to be more specific with the
>>     deliverables and milestones in the final proposal. I would love
>>     some feedback, and if I have misinterpreted or neglected
>>     something, please tell me so I can fix it for the final proposal!
>>     :) I am really excited to get in touch with you all and
>>     (hopefully) get started with this project.
>>
>>     Thanks a lot!
>>
>>     Best regards,
>>     Håkon Vågsether
>>
>>     
>> https://drive.google.com/file/d/0B1ylsmzHTJ7AQ01lNDYzMHZweVk/view?usp=drivesdk
>>     
>> <https://drive.google.com/file/d/0B1ylsmzHTJ7AQ01lNDYzMHZweVk/view?usp=drivesdk>
>>
>>
>>
>>     _______________________________________________
>>     Discuss-gnuradio mailing list
>>     address@hidden <mailto:address@hidden>
>>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> 
> 
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>