[Kde-bindings] KDE/kdebindings

[Arno Rehn]

On Wednesday 19 May 2010 23:16:14 Andreas Pakulat wrote:
> On 19.05.10 22:47:57, Arno Rehn wrote:
> > SVN commit 1128652 by arnorehn:
> > 
> > remove kdevplatform. it's broken.
> 
> Hmm, can this be fixed? I'm guessing someone would need to take care of
> whatever is being used to generate the bindings?
No, the mistakes are mostly in KDevPlatform's headers.
See here:

/usr/include/kdevplatform/vcs/interfaces/ibrowsableversioncontrol.h:92:1: 
error: expected unqualified-id before ‘namespace’
/usr/include/kdevplatform/vcs/interfaces/ibrowsableversioncontrol.h:92:1: 
error: specialization of ‘template<class T> T 
qt_extension(QAbstractExtensionManager*, QObject*)’ in different namespace
/usr/include/QtDesigner/extension.h:94:74: error:   from definition of 
‘template<class T> T qt_extension(QAbstractExtensionManager*, QObject*)’
/usr/include/kdevplatform/vcs/interfaces/ibrowsableversioncontrol.h: In 
function ‘T qt_extension(QAbstractExtensionManager*, QObject*) [with T = 
KDevelop::IBrowsableVersionControl*]’:
/usr/include/kdevplatform/vcs/interfaces/ibrowsableversioncontrol.h:92:1: 
error: ‘IBrowsableVersionControl_iid’ is not a member of ‘KDevelop’
/usr/include/kdevplatform/vcs/interfaces/ibrowsableversioncontrol.h:92:1: 
error: ‘IBrowsableVersionControl_iid’ is not a member of ‘KDevelop’

[endless list of follow-up errors]

This is a syntax error (a missing closing brace for 'namespace KDevelop' I 
think), but there's also a huge bunch of methods that are declared in the 
public API but are simply not implemented (or exported).

Take a look at how many methods we have to blacklist to have it compiling: 
http://websvn.kde.org/trunk/KDE/kdebindings/smoke/kdevplatform/smokeconfig.xml?view=markup&pathrev=1128651

Could be that some or all of these issues are now fixed, but I haven't taken a 
look at current KDevelop trunk yet.

> Its not overly important to have bindings for kdevplatform as we
> currently don't support loading non-c++ plugins anyway, but we do want
> to be able to do that at some point in the future. Hence I'm checking
> what exactly is broken.
Yes, I definitely want C# and Ruby support in KDevelop - so we'll also need 
kdevplatform. But currently I feel it's still a bit unstable (the API, not the 
app itself. I use KDevelop4 regularly :)).
I think we should rather add it again when we really need it.

-- 
Arno Rehn
arno at arnorehn.de