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

[Chris Burel]

>> 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.