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

[Martin Braun]

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.

>> Also, I'm very interested in benchmarks. If there's some effort involved
>> here, it has to pay off in terms of speed.
> 
> I don't think there are any speed advantages for blocks coded in C++,
> what can be sped up is instantiation and configuration of the blocks.
> The actual work methods are already called in C++ context without Python
> overhead, so there is nothing to to gain there.
> 
> This is different for blocks coded in Python, but to take advantage of
> the improved SWIG wrappers other changes would be required, probably.
> There is quite a bit of magic involved at the moment, that can be
> probably simplified with better wrappers.
> 
> However, I have the feeling that if speed is a goal, SWIG is probably
> not the right tool. The code it generates it sub-optimal under many
> aspects (starting with the double type system it puts in place: the SWIG
> type system somehow glued on top of the Python type system...)

SWIG isn't going anywhere soon. But if we can improve on what we have,
that's interesting.

>> I'd suggest you open an issue on our tracker, and we take the discussion
>> there. I'm hoping that that some people with more SWIG experience can
>> chime in here, too.
> 
> I'll do.

Thanks!

M