koala

[Richard Dale]

On Sunday 28 April 2002 6:45 pm, David Faure wrote:
> On Sunday 28 April 2002 19:34, Richard Dale wrote:
> > On Sunday 28 April 2002 5:00 pm, Bernd Gehrmann wrote:
> > > On Thursday 18 April 2002 09:36, you wrote:
> > > > I keep a patch of any manual edits needed for the previous version,
> > > > and apply that to the newly generated sources. It would be nice to
> > > > completely automate it, but I'm not sure if it's possible (cf
> > > > kdebindings/kdejava often fails to build too). Possibly the unedited
> > > > sources could go in the cvs under an 'AUTOGENERATED_BINDINGS' tag, so
> > > > that the manual edits would be the difference between this and the
> > > > HEAD branch.
> > >
> > > You could also commit the patch into cvs. Regenerating the sources
> > > could then done with a Makefile target
> > >
> > > regenerate:
> > >         kalyptus something
> > >         patch < patch
> > >
> > > Whenever you change your manual modifications, you can update the patch
> > > with
> > >
> > >   cvs diff > patch
> > >   cvs commit patch
> >
> > Or a third approach would be to put the unedited sources into a different
> > directory.
> >
> > I did start updating the javasupport part last time you mentioned koala,
> > but I'm afraid I got distracted with something else. The problem is that
> > the names of some of the core api classes have changed, and most of the
> > work is tracking down which new name corresponds to which old name.
> >
> > I would certainly like to decide on the definitive way to do this. David
> > Faure also has an opinion on how it should be done, so I'll cc him this
> > mail.
>
> I hate manual edits on generated stuff ;)
But manually producing .pig or SWIG interface files as input instead of using 
the headers 'as is' is 10 times worse. I need to go through what the java 
manual edits and see what they consist of and how many of them can be 
elimanated. When I started doing language bindings I was amazed I could 
manage to wrap the Qt/KDE apis at all, let alone do it completely 
automatically :). The Gnome project have always made a fuss about the variety 
of gtk bindings available, but all of their projects are incredibly labour 
intensive and slow to progress.

> So ideally, any "hack" to be done after re-generating should be done by a
> script (or a diff as mentionned above), which can then be part of the
> rebuilding process. My idea for that was a separate script to run by hand,
> but a Makefile target does the job too. It's just much harder to find, it
> must be well-documented!
>
> I think ./regenerate is simpler than "make regenerate", because "ls" tells
> you this possibility exists.
>
> I am a bit against the idea of a separate cvs branch - they are usually
> quite a mess to manage, they would lead to much bloat in the history of the
> files, and on kde-cvs....
>
> Just my 0.02 EUR, you're the maintainer ;)
>
> If the edits are so big that they can't be scripted or patched, then
> obviously a more manual solution is in order. But for sure I won't let that
> happen to the perl bindings (and from reading the C# binding I'm quite sure
> it doesn't need any either). Do the java bindings really need _manual_
> editing after each regeneration?
Do you deal with multiple inheritance yet? Possibly the java bindings attempt 
to do more than C# or perl ones currently do. But it's great to have other 
people reviewing the approach so I can think about it afresh..

It certainly isn't always possible to tell if a QString argument is read-only, 
read-write or write-only (I would like kdoc tags in the headers to indicate 
that).

-- Richard