Uploaded image for project: 'Qt for Python'
  1. Qt for Python
  2. PYSIDE-1240

APIExtractor as a first class tool, and as a backend for binding generators / using APIExtractor standalone



    • Type: Suggestion
    • Status: Closed
    • Priority: Not Evaluated
    • Resolution: Won't Do
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Shiboken, Tooling
    • Labels:
    • Platform/s:


      I'm overdue to open this issue, per previous IRC discussion with Cristian Maureira-Fredes
      and Friedemann Kleint, I appreciate your help, and being available to discuss this!
      I was also told people have asked similar things before.

      Haskell does not have a good native GUI story. Bryan Gardiner is writing raw, non-
      idiomatic bindings to Qt in Haskell ( http://khumba.net/projects/qtah/ ) using his C++
      FFI generator ( http://khumba.net/projects/hoppy/ ).

      Currently every foreign class, function, etc. definition is hand written, so the
      coverage of the Qt API is quite low. An example specification for QPushButton can
      be seen on the hoppy page, and a version of the documentation listing what
      functions exist can be browsed at https://hackage.haskell.org/package/qtah-qt5-0.5.1

      My understanding is the following:

      PySide/Shiboken contains a component called APIExtractor, which leverages
      CLang/LLVM to inspect the Qt codebase and acquire information necessary for
      binding generation.

      However, currently the tool is only exposed through a static library used by
      Shiboken, and the information it extracts cannot be accessed in a standalone

      Furthermore, I see no reason why the information could not be dumped to a
      language-agnostic database for every Qt release+, allowing the information to be
      used without needing to run the tool at all. I hypothesize this will promote
      binding generation to any language.

      +(I would /personally/ prefer this not to be XML)

      Thus, I propose:

      • give APIExtractor a CLI frontend, with documentation
      • compile APIExtractor as a shared library, and document the code
      • release a pre-generated language-agnostic information database with every qt

      Per the previous discussions, I'm told the Qt documentation generator also uses a
      somewhat similar approach (for getting function signatures into the
      documentation?) - this is more evidence that benefits can be had from a standalone

      There are probably additional applications here. I don't know if the KDAB GammaRay
      people would have use for such a database?


      (Somewhat tangentially, Friedemann Kleint mentioned the attachment of
      https://bugreports.qt.io/browse/PYSIDE-323 as related / more lightweight)


        No reviews matched the request. Check your Options in the drop-down menu of this sections header.



            kleint Friedemann Kleint
            deliciouslytyped nope nope
            1 Vote for this issue
            4 Start watching this issue



                Gerrit Reviews

                There are no open Gerrit changes