[Kde-bindings] Readable GCC dump parser

[Ashley Winters]

--- Alexander Kellett <lypanov at kde.org> wrote:
> On Sat, Aug 02, 2003 at 03:21:36PM +0200, Alexander Kellett wrote:
> > okay. just to check if i've got this right.
> > kalyptus would be partially replaced by this 
> > then smoke would be modified to use the xml api.
> > and in principle perlqt/kde and *ruby would not
> > really require all that much work other than a
> > few namespace changes and a ton of data type 
> > (de)marshallers?

I want to split Smoke into 2 pieces, effectively into Smoke and a
Mirror.

The "flaw" in Smoke's design is that it never forces Qt to work down at
the lowest-common-denominator, C. It works at a higher level, which is
all I needed for dynamic language like Perl (and, it seems, without
modification for Ruby).

While this serves the purposes of Qt just fine, it does squat for the
goals of KDE, which needs the kind of flexibility to be used from
non-C++ compiled languages. I provided nice innovations (like virtual
function support and signal/slot voodoo) without making them accessible
to compiled languages.

So, the new Smoke will take an XML API for Qt/KDE/Whatever and flatten
it out into a C library, and then provide a separate library to make it
accessible through marshallers and such to dynamic languages like
Perl/Ruby/Python.

The Mirror library will provide the introspection into Smoke needed for
the autoload trickery we do to avoid having to declare all the Qt
functions. Essentially, it's the new name for the
function-lookup-trickery that Smoke does now. It will just be generated
from the XML file, instead of Kalyptus.

As for requiring work, I'm hoping everything will stay
interface-compatible with the current Smoke. I don't want to break
stuff. 

> oh, and i missed the most important
> question. what about users without gcc?
> maybe the generated xml could be in cvs
> itself, i'd imagine that its not quite
> so huge as the generated code itself?

It's huge. And, it's not completely portable. GCC imposes its
environment harshly onto Qt (ever seen -Dbool=int?) and that imprint is
left, unportably, on the API it generates. Whether this would be big
enough to make a 32-bit => 64-bit compiliation fail, I dunno yet.

As for not having GCC, I'm probably not going to use GCC proper. The
www.gccxml.org folks forked the parser from GCC and tweaked it to come
up with more informative XML snippets. It's indepentent from GCC, and
works on Windows even (it'll parse MSVC voodoo). Fortunately, I've
already written a ghetto XML-compatible version of the gccxml parser
(in Perl, of course) which works with regular GCC, so we aren't
dependant on the gccxml folks if their project ever collapses horribly
(a possibility I always consider distinctly, given PerlQt's own
checkered past back when I was writing it). :)

Ashley Winters


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com