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?
–
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.
On 08/07/2013 04:32 PM, jrobison wrote:
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.
PS
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
-josh