Re: Python bindings using cppyy (was: An update on Python bindings)

Hi all,

I have a preliminary version of the Cppyy bindings generator CMake
support available here:

    https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-experimental-version-of-a/diff

There are some TODOs yet to be addressed, but I would appreciate
feedback on how easy it would be to integrate this with KDE's
buildsystem, especially for the frameworks. I'm a CMake noob, but the
basic idea I have is that the packager of some_framework might do
something like this:

find_package(cppyy)
CPPYY_ADD_BINDINGS(
    ...
    LINK_LIBRARIES some_framework_LIBRARIES
    H_DIR some_framework_INCLUDE_DIRS
    H_FILES <list_of_h_files>)

Thanks, Shaheed

On 16 October 2017 at 16:16, Shaheed Haque <[email protected]> wrote:
> As promised, here is an interim update on the investigation into the
> use of cppyy-based bindings for KF5 (and more...) instead of SIP-based
> bindings.
>
> The first thing is that the underlying technology of cppyy,
> cling/ROOT, has been under development at CERN for quite a while. It
> directly reads regular C++ files (there is no intermediate format like
> SIP).
>
> The bindings it generates from Python to C++ seem far more complete
> and automatic than SIP. For example:
>
> - Template instantiation is done on the fly as needed.
>
> - Since it uses C++ directly, there is none the effort required to
> decollide SIP's notion of forward and duplicate declarations.
>
> - Function overloads are cleanly handled, as are most (all?) operators.
>
> The net result is that so far, there is about 3 days work and
> approximately [1] no "customisation" required in order to get to
> roughly where the SIP based bindings were after 18 months. Without the
> need for customisations on a mass scale, I suspect that we might get
> away without anything like the tooling I had to create to SIP, and
> just integrate with CMake
> (https://root.cern.ch/how/integrate-root-my-project-cmake).
>
> This all sounds pretty amazing, right? Well, there are a few caveats...
>
> - The packaging is pretty new, and is evolving pretty rapidly. We
> are/will be an early adopter (https://bitbucket.org/wlav/cppyy/ and
> https://bitbucket.org/wlav/cppyy-backend). Packaging is via PyPI and
> pip/pip3.
>
> - There is a lot of documentation around for the system overall, but
> frankly, it has  been/still is a struggle to understand how the
> different parts relate to each other as some parts are obsolete, and
> other parts have yet to be built out to their intended end-state.
>
> - There are bugs [1], [2]. The upstream dev has been very responsive,
> and the overall quality approach looks sound. IIUC, the vast bulk of
> the code seems to be in daily use at CERN (and is based on LLVM).
>
> - Need to look into the exact usage of Qt-specifics: signals/slots and
> interoperability with SIP-based PyQt
> (https://root.cern.ch/root/htmldoc/guides/users-guide/PythonRuby.html#glue-ing-applications,
> https://root.cern.ch/doc/v606_ORIG/guide/ROOTandQt.html)
>
> - Need to figure out how any customisations which *are* required
> should be handled.
>
> These seem like perfectly tractable issues, and so I conclude that
> using cppyy is definitely the way to go. With luck and a bit of
> effort, I am hopeful that we can get to some REALLY
> easy-to-develop-and-maintain bindings.
>
> [1] There is a bug with the binding producing stuff for private definitions.
>
> [2] There is a bug with missing globals.
>
>
[snip]