[Kde-bindings] Re: Transition to Git and reorganization of kdebindings

[Arno Rehn]

On Saturday 20 November 2010 02:33:10 Chris Burel wrote:
> >> My usecase:
> >> We (my company) are starting to use smoke not only for Qt bindings but
> >> for "any" c++ lib we need and sometimes it can be real pain to download
> >> part of KDE stuff to a production server where we need to use for
> >> example memcached smoke bindings...
> 
> I'm in the same boat.  I've got PerlQt set up so that it can load any
> arbitrary smoke library, not necessarily tied to Qt at all.  But it
> still stinks because PerlQt uses Qt datatypes internally for core
> functionality.  And that makes it really strange that the generator
> code puts global functions in QGlobalSpace.  I'd think it'd be great
> to have a smokebase module for each target language, that didn't use
> Qt at all, and you could define where the global functions ended up.
Initially, there was a way to define which class to use for global functions. I 
just abandoned that because QGlobalSpace doesn't have any connection to Qt at 
all (except for the name) - so it could just be seen as some kind of historic 
artifact.
Regarding your Qt dependency: I don't think it's bad to have a dependency on 
QtCore for the bindings. If you don't want to rely on the C++ STD libs, you 
need an external dependency for the bindings. Either it's Qt or Boost or 
something else - and I think QtCore is the best choice here.

-- 
Arno Rehn
arno at arnorehn.de