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 <srha...@theiet.org> 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]