[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] SWIG CVSD error

From: Josh Blum
Subject: Re: [Discuss-gnuradio] SWIG CVSD error
Date: Thu, 08 Aug 2013 04:54:55 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

On 08/07/2013 04:32 PM, jrobison wrote:
> I am trying to generate java interfaces for SWIG (2.0.10) under fedora 19 ,
> but I'm getting an error. I've been using the command 
> swig -java -c++ -I$SWIG_INCLUDE $SWIG_INCLUDE/vocoder_cvsd_decode_bs.i
> This returns the error:
> /usr/include/gnuradio/swig/vocoder_cvsd_decode_bs.i:38: Warning 401: Nothing
> known about base class 'gr_sync_interpolator'. Ignored.
> No module name specified using %module or -module.
> I've on and off tried options like -includeall, -importall, and some others,
> no difference. I would have thought SWIG would recursively go in and
> generate the gnuradio specific interfaces cvsd depends on from the imports,
> but it didn't seem to, so I started adding them manually with -l. I'd chip
> away at different errors, then get to std_types, which seems wrong. How are
> you guys building the bindings with SWIG such that it can figure out this
> hierarchy?

I think what you are trying to do is a way deeper hole than you realize.
You probably cant just run swig with -java on the installed .i files and
just have java support like that. Many of the .i files rely heavily on
the build system, or have python specific stuff, or could be quite
fragile. Sorry to be discouraging, its just a very deep
framework-architectural thing.


I have some swig + csharp experience (which according to swig docs are
almost identical to java swig). You can basically have the same .i files
as python, which is nice. You can even #ifdef SWIGPYTHON or SWIGJAVA
parts of it. One of the missing features for me was that there was no
equivalent of %pythoncode for the other languages... Anyway what you do
with the generated source from swig is pretty different (compile, link,
installation, organization). So it would have to be all generalized out
in the build system.

I think it would be really cool one day to have all the blocks in the
block factory. Then you just add support for languageX to the
framework/factory; which isnt trivial, but you do it just once. But
because all of the blocks are registered in the factory, you just get
the new language support automatically. Maybe some rainy day or two...

Just my 2cents

> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/SWIG-CVSD-error-tp43026.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

reply via email to

[Prev in Thread] Current Thread [Next in Thread]