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

    XMLWordPrintable

    Details

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

      Description

      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
      manner.

      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
        version

      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
      tool.

      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)

        Attachments

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

          Activity

            People

            Assignee:
            kleint Friedemann Kleint
            Reporter:
            deliciouslytyped nope nope
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Gerrit Reviews

                There are no open Gerrit changes