[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: [Kde-bindings] Re: Transition to Git and reorganization of
From: Arno Rehn <arno () arnorehn ! de>
Date: 2010-11-20 12:39:37
Message-ID: 201011201339.37284.arno () arnorehn ! de
[Download RAW message or body]
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@arnorehn.de
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic