discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin opti


From: Daniele Nicolodi
Subject: Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option
Date: Mon, 20 Oct 2014 14:06:22 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 20/10/14 13:46, Martin Braun wrote:
> On 10/20/2014 12:16 PM, Daniele Nicolodi wrote:
>>> Having to write .i files for everything would be a nuisance, given that
>>> we mostly got rid of that in 3.7.
>>
>> I don't understand what you mean with this. We have .i files for
>> everything! For out-of-tree modules they are auto-generated by
>> gr_modtool and some parts are hidden behind SWIG macros, but there
>> definitely are .i files for all the classes in GNURadio. It is how SWIG
>> works :)
> 
> No, we barely have any (unless you're using a very old GNU Radio). We
> have top-level .i files which include the actual block header,
> per-in-tree component if that's what you mean. We do *not* need to write
> .i files for every block (and are glad about it :).
> The few modifications we need these days are taken care of by modtool.

Now I see what you mean, but the fact that the .i files are quite small
and mostly auto-generated does not change the fact that we need the .i
files to tell SWIG to generate code for the blocks :)

The .i files for regular GNURadio blocks are not going to change much
with the switch to builtin object classes. The only changes required are
related to providing a __repr__() method because, unfortunately, the
glued on swig type system does not make it possible to have it inherited
from parent classes, at least as far as my understand of SWIG goes.

I'll try to have a branch with my changes ready to review soon, so we
can talk about something more concrete.

Cheers,
Daniele




reply via email to

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