[PySide] Generator RoadMap (Was: PySide is Dead?)

[anatoly techtonik]

On Mon, Dec 10, 2012 at 8:32 PM, Hugo Parente Lima
<hugo.lima at openbossa.org>wrote:

> On Monday, December 10, 2012 11:26:47 AM John Ehresman wrote:
> > On 12/10/12 8:38 AM, Hugo Parente Lima wrote:
> > > Is normal, our the binding generator code base is a mess to
> > > understand due to various historical events occurred during the
> > > development, in the ideal world the generator would be written in
> > > Python with a clean code base, just the helper libraries in C++
> > > (libshiboken and libpyside), but this would require a full rewrite
> > > of the generator :-/. Our typesystem file inherited from Qt-Jambi
> > > is also not the better way to give hints to the generator about how
> > > to generate bindings.
> >
> > My thought on the code generator was to have the C++ parser write the
> > parse tree out to some xml file that could then be read by a code
> > generator written in python.  Then the C++ parser could possibly be
> > replaced with something else and the generator could be more quickly
> > improved since it's now implemented in python.  Changing it would
> > still require C++ knowledge, though, because it's emitting C++ code.
>
> There's GCCXML[1], so the python program just read the output of GCC XML
> plus
> some other file with meta information equivalent to the current typesystem
> but
> less verbose and outputs the binding code, seems easy, but it's a
> looooonnng
> task.
>
> [1] http://www.gccxml.org/


Here are three parsed AST formats:
http://www.gccxml.org/HTML/example1out.html
http://clang.llvm.org/docs/IntroductionToTheClangAST.html
http://code.google.com/p/pycparser/

The first step is to hack PySide C++ parsing code in two parts at the point
where it produces output. Then take the first part and teach it to spit AST
in the most suitable format. Also document "interesting" things that happen
along the way - like global variables that are set and accessed later
(these might not exist at all). Record the outcome (in the RoadMap or
separate doc).

The second step it to take the second part and teach it to consume the
resulting AST. This will also discover things that are missing for this
part to operate successfully.

The third step is to create PSEP with description of current problems,
provide some pictures of the process for documentation and describe how the
wrapping works.


Parallel work for marketing, PR and fundraising talent: collect user
stories, identify major tasks that need to done, wrap both into sponsor
packages and make them available for the interested parties. To make these
more attractive for the sponsors, the LGPL could be replaced with more
relaxed terms for maximum reuse. Sponsorship does not necessary mean money
donations. It could easily be a GSoC project.


Now about academic value and points of interests. What I (as a person who
don't do C++) would like to see from C++ parser is a picture of the
structure of complex C++ project that consists of many dependencies. The
biggest problem for me always was *implicit* inclusion of some header files
from out of nowhere and injection of symbols in global space. It will be
extremely useful if parser could reconstruct fully qualified names of all
symbols (the resolution step that is done by compiler and linker during the
build process). Fully qualified name is "package.module.function" where
"package" concept maps to "directory" and "module" is equal to "header file
name without extension". If the parser could fully dump nested (indented)
tree of all used symbols including the missing ones (which are impossible
to resolve) - then it can also be useful for other things. Such
as automatic dependency resolution in a build system.
-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20121218/e0f7c302/attachment.html>