[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] Replacing kalyptus
From:       Paolo Capriotti <p.capriotti () gmail ! com>
Date:       2007-10-03 16:34:01
Message-ID: 200710031834.01860.p.capriotti () gmail ! com
[Download RAW message or body]

On Wednesday 03 October 2007 18:10:31 Arno Rehn wrote:
> Am Mittwoch 03 Oktober 2007 17:45:45 schrieb Paolo Capriotti:
> > On Wednesday 03 October 2007 17:15:22 Arno Rehn wrote:
> > > I've quickly looked through moc's code and hacked it a bit here and
> > > there and the results look promising, so what do you think?
> >
> > I suggest you to take a look at gccxml. Mauro Iazzi is successfully using
> > it for the binding generator on which lqt is based.
> > A big advantage with respect to moc is that it parses arbitrary C++ code
> > (IIRC it works as a gcc backend).
>
> I've already done that, but besides the output being quite difficult to
> read I don't see how we can differ between a signal, a slot or a ordinary
> method. Further it doesn't parse the Qt headers for me, it always exits
> with a syntax error detected.
> Anyway, I'll ask Mauro how he uses it. Thanks for the tip.

One possible solution to distinguish between signals and normal methods is to 
define the macro signal (or Q_SIGNAL, if QT_NO_KEYWORDS is defined) as a 
gccxml attribute. Same for slots.
Another possibility is to run moc over the sources and parse the generated cpp 
file. This sounds harder and uglier, though.
I don't know about the syntax errors. I've not yet tried to compile the Qt 
sources with gccxml.

Hope that helps,

Paolo
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]