[Kde-bindings] Splitting up the Smoke qt library into modules

[Arno Rehn]

On Wednesday 21 October 2009 19:36:35 Richard Dale wrote:
> While we're discussing BIC changes to the smoke libs, I wonder if it would
>  be a good idea to split up the libsmokeqt library into small libs. The
>  small size of the Smoke libs is becoming a big advantage relative to other
>  bindings libraries, and it we split them up a bit maybe the advantage
>  would  be larger still. Or is the a performance tradeoff in that searches
>  for a class or method would have to cross Smoke module boundaries more
>  often and that would slow things down? It is worth measuring somehow?
Since it's all cached once it has been looked up, I doubt that the performance 
tradeoff is noticable.

> For a start I really thing we should remove QtXml and QtSql from the base
> Smoke library as nearly all dynamic languages have their own versions of
>  there which are quite likely to be better than a wrapped C++ version. For
>  example, there in no point in using the QtSql classes in Ruby because
>  Rails ActiveRecord is so much better.
With the new smokegenerator that should be a trivial task, so we could split 
everything at once.

> Then the decision is whether it is a good idea to map one Qt module onto
>  one Smoke library.
I don't see anything that would speak against it.

> One example for me, is that I think a separate QtCore smoke library would
>  be useful for Semantic web applications, as I could use the Ruby bindings
>  for QtCore, Soprano with the ActiveRDF Virtuoso adaptor with Wt::Ruby for
>  the web app without the overhead of the QtGui library.
If we're at it I think we should also split the C# assembly into qtcore, 
qtgui, qtsql etc.

-- 
Arno Rehn
arno at arnorehn.de