[Kde-java] Re: GCJ (Re: Build system for KDE4)

[Martijn Klingens]

Richard Dale said:
> The java bindings are autogenerated - the kalyptus tool is driven by a
> list of
> headers in kdebindings/smoke/qt/header_list. It should be a matter of
> adding
> your library headers to that list, then editing the 'generate.pl' script
> in
> smoke/qt changing the kalyptus option '-fsmoke' to '-fjni', then type
> 'perl
> generate.pl'. It will generate .java and .cpp sources. You then use javah
> to
> generate the .h files from the compiled java classes.

Hmm, with some small changes it can indeed be made generic enough to
support libs other than qt and kdelibs too. In theory it can even become
part of the build system to auto-import a C++ lib into Java code and do
all the binding generation and linking automagically.

> But the package names are hard coded - any classes beginning with 'Q' go
> into
> org.kde.qt and all others go into org.kde.koala. So maybe when we decide
> on a
> better package naming scheme, the bindings generator ought to allow any Qt
> headers to be used for bindings generation and not just the ones in the Qt
> and KDE libs. Maybe a configuration file is needed for C++ classname to
> Java
> package/classname mappings.

In the case of kextprocess it's namespaced C++ code. There's the
KExtProcess namespace with several classes in it. The most 'natural'
namespace for Java in terms of typing and grouping would probably be
<classname>.extprocess.kde.

-- 
Martijn