Re: How to write Gnuradion OOT C++ method as a stand alone .cc file?

[George Edwards]

Hi Martin,

 

Thanks for the response! 

The OOT module compiles when I do: cmake ../ and make, however, the QA test fails and gave the following error warnings

 File "<frozen importlib_bootstrap>" (for different lines in this imported file)

Now what is also disconcerting is that if I try to run another QA test that previous worked in the past for another (OOT module), it fails and gives the identical error messages. This does not make sense to me, I thought each OOT module even though created in the same directory was its own entity and used its own individual branch in that python file to which the modules are all added. 

Do you have any idea as to:

1)  What I may need to add to the stand alone file ,cc file to fix the  File "<frozen importlib_bootstrap>" error problem.

2) What would cause previously created OOT modules that run properly in the past to suddenly stop running and give the identical error as this new and failed OOT module using the stand alone .cc file. It seems as if the QA system test is now broken (and, I expected each QA test to run on its own merit)?

Thanks for your help.

Regards,

George

On Thu, Aug 20, 2020 at 7:10 AM Martin Braun <martin.braun@ettus.com> wrote:

George,

all the usual linking and compilation rules of C++ apply. There are plenty of blocks that call other functions from general_work() or work(). If you're compiling a-OK, then you're probably halfway there. Your QA code should tell you what's missing, if it's a missing symbol (i.e. linker error) or something more profane.

--M

On Thu, Aug 20, 2020 at 5:56 AM George Edwards <gedwards.eng@gmail.com> wrote:

Hello,

I am experimenting with writing an OOT method in a separate .cc file to be called by the general_work method that Gnuradio automatically generates when one uses the gr_modtool to create an OOT module. In general if the method is short, it is convenient to write its definition about the general_work method which called it. However, if the signal processing makes the method long with too many lines of code, then it is better to create a separate .cc file for the function. I made the additional .cc file and wrapped the method in a similar manner to how the gr_modtool  wraps the .cc file My_ProgramName.cc. The new .cc file shows no errors and I compiled the entire OOT module with: cmake ../ and make. However, when I run the QA test, it breaks the  system. Below is a template showing how I wrote the additional file named, my_function_name.cc:

#include <gnuradio/io_signature.h> 

#include "My_ProgramName.h"      // created by gr_modtool

namespace gr {

namespace tutorial {

gr_complex

 My_ProgramName_impl::my_function_name(param)

       {

       // my signal processing algorithm goes here

        }

   }  //namespace tutorial

}     //namespace gr

I will appreciate your feedback or help, so I can get my method to work and not break the system when I run the QA test.

Thank you!

George