[Kde-bindings] Replacing kalyptus

[Arno Rehn]

Am Mittwoch 03 Oktober 2007 18:03:33 schrieb Richard Dale:
> On Wednesday 03 October 2007 16:21:19 Arno Rehn wrote:
> > Am Mittwoch 03 Oktober 2007 17:15:22 schrieb Arno Rehn:
> > > Hi,
> > >
> > > Since it's pretty obvious that kalyptus is merely maintainable [...]
> >
> > Er, that should be a 'barely'...
>
> Actually I don't have too much trouble maintaining kalyptus considering how
> complicated it is - you are talking about 6 man months work for a
> replacement in my opinion.
Well, if you can maintain it, that's ok. But it might be a nice idea to add a 
XML backend for kalyptus, so you're not bound to Perl for writing binding 
generators.

> I don't think the moc parser is good enough, and we should use one of
> Roberto Raggi's full blown C++ parsers like the KDevelop one, or another
> one that the QtJambi bindings use.
Why a full blown parser? The only thing we need is something that gathers all 
the namespaces, classes and methods with return type and parameter types (and 
if it's a signal/slot). I think moc provides all that stuff.

> But that is a huge amount of work, and 
> it is much more important to get your stuff with modular smoke working
> first.
Actually I'm still trying to find a way to convert QtRuby to modular smoke 
without having to rewrite too much of the code. And since ruby-doc.org always 
produces an error when I try to access the C API reference, I only have a 
very vague idea of how to use the C interface.

> And then simplify the over-complicated perl config stuff and use 
> straight cmake tests instead.
>
> I am still trying to get back into bindings development again, after back
> trouble, feeling burnt out, and too much day job work to do.
>
> It's the build system stuff like 'qtguess.pl.cmake' that is really
> difficult to maintain, and I that I would like to get rid of first.
I'd just let gcc resolve which defines exist. Write a small app with
#ifdef QT_NO_FOOBAR
	printf("QT_NO_FOOBAR\n");
#endif
for every define that should be tested, compile it and run it. It should run 
way faster than the perl script and be more convenient to maintain. The 
source could be autogenerated from a list of defines that should be tested.

> I'm 
> still trying to manage to reply to Dirk's recent mail about how the kde
> smoke bindings are unbuildable. In fact I've been able to build them fine,
> apart from kde headers coming and going every other day (latest examples
> are kfilefilter.h and kcatalog.h going AWOL).
Same goes for me. I've never had any trouble with building the bindings.

-- 
Arno Rehn
arno at arnorehn.de