Now that the Qt classes generate and compile fine (as Richard already wrote) I tried to generate the smokekde sources with the new generator last week.

After fixing quite a bunch of bugs that didn”t surface when generating smokeqt, it works now really well.
There isn”t much difference between the config files for qt and kde, too – it”s mainly the lists of stuff to include and very little stuff to be excluded (d pointers, q pointers, other private stuff…).
This really shows that the new parser is superior to kalyptus, which had dozens of hacks in it for the code to generate nicely.

In case you want to test it, get the source from /trunk/playground/bindings/smokegenerator. To make testing easier, I wrapped the generation in cmake, so a normal cmake; make; make install should build and install smokeqt and smokekde for you.

The new generator still generates a lot of code for deprecated methods, which isn”t really nice – but maybe the parser can be modified so it recognizes __attribute__((deprecated)) flags.
There are also still issues with fixed-width array types, which luckily don”t occur too often in KDE sources. This only affects KMD5 for the moment. I”ll fix this next week, so then should smokekde with smokegenerator be equal to smokekde with kalyptus 🙂

Hi,

my name is Arno Rehn and I”m a bindings developer. I”m working mainly on the C# bindings for Qt and KDE together with Richard Dale.

Currently I”m also working on my gsoc project – Rewriting the SMOKE generator using one of Roberto Raggi”s C++ parsers.
SMOKE is a library which provides the possibility to dynamically call methods on classes. It is the foundation for many of the Qt/KDE bindings, like Ruby, C# and PHP.
The old generator for the SMOKE sources is based on a perl tool, kalyptus, and only works with a bunch of hacks in the code. It tends to break on new releases of Qt or KDE which introduce new features.

The goal of my project is to create a stable and robust tool, similar to the moc, which you just run on the headers of your project and you then end up with a bunch of source files that are the basis for bindings for your project.

Eventually I decided to use the new parser from KDevelop4, since that has a pretty convenient API (unlike the QtJambi / qtscriptgenerator one). It took some time to remove the KDevPlatform/KDevelop specific bits, though. It would”ve also been nice if I could”ve used the DUChain from KDevelop, but that seems to be so tightly integrated that I would have to provide half of KDevelop to use it.

I”m pretty much ahead of time – the generator is nearly finished. By the end of the GCDS, which I”m attending until Thursday, it should be working completely – at least with the Qt classes.

P.S.: I know that gsoc has started quite some time back, but I was really to lazy/busy to start a blog 😉