Re: [Discuss-gnuradio] [GREP] Replace SWIG

[CEL]

Hi Andrej, hey folks,

> Development of Python bindings with PyBind11 could even happen in a
separate CMake project

hm, that sounds like an additional complication,

On Wed, 2019-01-09 at 17:07 +0100, Andrej Rode wrote:
> since the only thing required for Python
> bindings are available headers and shared libraries.

While that is mostly true, working Python bindings are more of a core
feature than a lot of things that we keep around. 

Having a proper C++ block <-> Python object <-> GRC block isomorphism
is paramount to GNU Radio's transparency.

So, I'm very much worried that decoupling the generation and testing of
Python bindings from the main tree is counterproductive in terms of
"actually works". 

Also, most of our math-oriented unit testing happens in Python. I don't
want to start writing C++ unit tests, but I sure also don't believe
that a circular dependency
"In-tree unit tests" -> "Ext. Python Bindings" -> "In-tree C++ headers"
is in the interest of any one. The "external" becomes a lie, because
it's part of the internal testing.

>  Since that could
> be easier on new developers.

I'd ask you to elaborate on how? Yes, SWIG is ugly, but in-tree python
and in-tree swig files are divided from C++ code by a clear folder
hierarchy.

> I agree that currently most users are using Python as development
> environment and we should ship the bindings with GNU Radio itself.

So, same page?

> Also we had a discussion on generation of bindings and I don't see a
> need of automatically generated bindings during each build. 

Well, if our bindings weren't so intricate, but the same for every
block, then I'd agree with you; we'd just have to add
"another_block_ff" to the list of things that get the block-typical
wrapping.
But since that's not the case currently and we don't want things to
break on the Python/C++ boundary when someone changes the API of a C++
object but forgets to manually rebuild the bindings: not a big fan of
the idea.

Either the binding generation becomes reliable and reproducible, and in
that case we could just as well run it every time, or it doesn't; but
then we'll stick with SWIG, I guess, because that *works*.

> Maybe a
> first generation can be done using binder[0]. But since that is a
> separate tool I wouldn't want to depend on that to generate the sources.

> Rather add the bindings during code review (or have a checkbox to check
> for that during code review).

I don't think that binding generation should be a human's manual job.
Again, if it's easy to trigger programmatically (e.g. in a githook)
then we can just as well do it at build time.

Cheers,
Marcus


> Cheers
> Andrej
> 
> [0] https://github.com/RosettaCommons/binder
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature