[Kde-bindings] Replacing kalyptus
arno at arnorehn.de
Wed Oct 3 16:47:58 UTC 2007
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
> 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
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
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.
> 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 at arnorehn.de
More information about the Kde-bindings