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

Shaheed Haque srhaque at
Tue Oct 24 13:05:39 BST 2017

Hi all,

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

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:

    H_DIR some_framework_INCLUDE_DIRS
    H_FILES <list_of_h_files>)

Thanks, Shaheed

On 16 October 2017 at 16:16, Shaheed Haque <srhaque at> 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
> (
> 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 ( and
> 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
> (,
> - 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.

More information about the kde-core-devel mailing list