Re: [Discuss-gnuradio] New dsp block: no constructor defined

[Tom Rondeau]

On Mon, Apr 15, 2013 at 3:02 PM, LianFeier <address@hidden> wrote:
>
>
>> From: address@hidden
>> Date: Mon, 15 Apr 2013 10:18:26 -0400
>
>> Subject: Re: [Discuss-gnuradio] New dsp block: no constructor defined
>> To: address@hidden
>> CC: address@hidden
>>
>> On Fri, Apr 12, 2013 at 10:40 PM, LianFeier <address@hidden> wrote:
>> > ----------------------------------------
>> >> From: address@hidden
>> >> Date: Fri, 12 Apr 2013 19:44:26 -0400
>> >> Subject: Re: [Discuss-gnuradio] New dsp block: no constructor defined
>> >> To: address@hidden
>> >> CC: address@hidden
>> >>
>> >> On Wed, Apr 10, 2013 at 11:10 PM, LianFeier <address@hidden> wrote:
>> >> > Hi!
>> >> >
>> >> > I'm writing a signal processing block with gr-modtool. I've
>> >> > successfully make. When I try ctest -V, I get the "No constructor 
>> >> > defined"
>> >> > error. The swig interface file which gr_modtool generates is like:
>> >> >
>> >> > /* -*- c++ -*- */
>> >> >
>> >> > #define myblock_API
>> >> >
>> >> > %include "gnuradio.i" // the common stuff
>> >> >
>> >> > //load generated python docstrings
>> >> > %include "myblock_swig_doc.i"
>> >> >
>> >> > %{
>> >> > #include "myblock/myclass.h"
>> >> > %}
>> >> >
>> >> >
>> >> > %include "myblock/myclass.h"
>> >> > GR_SWIG_BLOCK_MAGIC2(myblock, myclass);
>> >> >
>> >> > I've seen some threads that said swapping the last two lines would
>> >> > help, but in my case it didn't. I'm using the latest version of
>> >> > gr-modtool(it generates xx_impl.cc,xx_impl.h and xx.h), and my gnuradio
>> >> > version is 3.6.0.
>> >>
>> >> No, you should be fine with the above setup. We fixed that issue a
>> >> while ago.
>> >>
>> >> > Could anybody kindly help?
>> >>
>> >> I'm not sure. This usually happens when swig isn't run correctly or
>> >> installed correctly (are you testing this just with QA code or after
>> >> installing it?).
>> >>
>> >> Can you write down what steps you took when building your code?
>> >>
>> >> Tom
>> >>
>> >
>> > Hi Tom,
>> >
>> > Thanks for your reply!
>> >
>> > I haven't installed it yet, i am testing it with the QA code.
>> >
>> > What I did after editing the files generated by gr-modtool is:
>> >
>> > In the directory of my block:
>> >
>> > mkdir build
>> > cd build
>> > cmake ../
>> > make
>> > make test
>> >
>> > I only edited the xx_impl.cc, xx_impl.h, xx.h ,qa_xx.py and the .i files
>> > among the whole bunch of files generated by gr_modtool. Is that all I 
>> > should
>> > do?
>>
>> Yep, that's what you should be doing. What version of the code base
>> are you working with? Is it a release version or from git? If using
>> git, are you using the very latest?
>>
>> > I can now actually piggyback my codes into gnuradio-core and rebuild
>> > gnuradio to use gr.myclass in python, but that seems to be very tedious. 
>> > Not
>> > sure whether this information helps.
>> >
>> > Thanks,
>> > Fei
>>
>> No, that's not what you want to be doing. One of the whole points of
>> this project is to allow you to write your own out-of-tree modules to
>> keep things simpler and more organized for your projects.
>>
>> Tom
>
> My code base is a release version from
> http://gnuradio.org/releases/gnuradio/  . I use gnuradio-3.6.0.tar.gz. My
> gr-modtool is from https://github.com/mbant/gr-modtool.
>
> Thanks,
> Fei


Ok, update to 3.6.4 and use the version of gr_modtool that comes with
that new release. Since you are just updating from 3.6.0, updating
will be easy since there are no API changes required, just bug fixes
and added features, like the inclusion of gr_modtool.

Tom