[Kde-bindings] Fwd: Re: Pre-approved Languages

[Sebastian Sauer]

eh, forgot to CC Jonathan who may not only those with the answer but can also 
provide us his pov as packager/distributor here ;)

----------  Forwarded Message  ----------

Subject: Re: Pre-approved Languages
Date: Thursday 01 May 2008
From: Sebastian Sauer <mail at dipe.org>
To: KDE bindings for other programming languages <kde-bindings at kde.org>

Cyrille Berger wrote:

> On Wednesday 30 April 2008, Richard Dale wrote:
>> > On Wednesday 30 April 2008, Allen Winter wrote:
>> > > On Tuesday 29 April 2008 18:34:29 Aaron J. Seigo wrote:
>> > > > of course, if bindings ever get made for another module we're going
>> > > > to be in this same boat again aren't we? i wonder if later on it
>> > > > might make sense to split up kdebindings into modules that reflect
>> > > > the KDE/ modules ... so kdebindings-libs, kdebindings-base,
>> > > > kdebindings-pim ...
>> > > >
>> > > > i assume this would be a major pain for the bindings teams, but
>> > > > would it be feasible? if so, when would be a realistic time frame
>> > > > for such a modification?
>> > >
>> > > Or, maybe each current module can have a bindings subdir?
>> > > i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...?
>>
>> The second suggestion seems sensible to me, with subdirs for each
>> language like kdelibs/bindings/python etc. Having a whole new set of
>> modules in parallel with the existing libs just seems to complicate
>> things. But I don't know enough about this discussion to know what
>> problem we're trying to solve.
> The problem is circular dependencies. A python applet was introduced in
> kdebase, which means kdebase depends on kdebindings while kdebindings
> depends on kdebase. The issue was solved by moving the python applet to
> kdeutils, but the problem might happen again in the future.

why not do it like we did with e.g. the Ruby Plasma backend and move it to 
kdebindings itself? The applet depends on python, that's what 
kdebindings/python/* is for. The applet depends on PyKDE which is in 
kdebindings/python/pykde4...

probably someone could argue that we would end with a kdebdings that depend on 
every other module, specially one more wrappers/libs come in, but we could 
still try to organize this somehow within kdebindings.

I mean, what happens if someone writes now an applet using QtRuby and moves it 
to kdeutils too. Would kdeutils end to depend on ruby, python, C#, java, ...? 
imho that's at least something that was solved in kdebindings with the (ruby| 
python|csharp|java|...) subdirs. That way an distributor could just package 
everything that depends on python and provide one big kde-(ruby| python|
csharp|java|...) tarball and if that's not enough, we could still add a 
theird hierachy to group things a bit.

-------------------------------------------------------