[Kde-bindings] A Qyoto pre-release

[Gary L. Greene, Jr.]

On Saturday 02 June 2007 03:50, Arno Rehn wrote:
> Am Freitag, 1. Juni 2007 schrieb Richard Dale:
> > On Friday 01 June 2007, Arno Rehn wrote:
> > > Am Freitag, 1. Juni 2007 schrieb Richard Dale:
> > > > Hi David
> > > >
> > > > On Friday 01 June 2007, David Canar wrote:
> > > > > I have created a pre-release package with the latest version of
> > > > > SMOKE and qyoto: www.qyoto.org (download section) Qyoto is working
> > > > > great! thanks Richard and Arno and all those who contributed!!
> > > >
> > > > OK good news. I think the problem with 'int&' arg types that we're
> > > > discussing at the moment is a bit of a show stopper, but doing a
> > > > practice package is certainly a good idea while we get it fixed.
> > >
> > > Well, the issue is solved now I think and so we can soon do the real
> > > release. But first I'd like to strong name qt-dotnet.dll so it can be
> > > installed into the GAC.
> >
> > I'm not sure what this involves, but installing into the GAC sounds a
> > good idea, and changing the cmake install rules so it does that.
> >
> > > Also it would be nice if all the sources are
> > > generated from the Qt headers. Generating the sources from the headers
> > > already works nice as far as I know, but when I tried it last time, I
> > > ended up with a lot of unnecessary files. I'd say we need to tweak the
> > > headers list then or add another file in which it says which files are
> > > actually used.
> >
> > Yes, by the time KDE4 is released I think we should do that. But while
> > we're still improving the code generation it's better to have the sources
> > in the svn still.
> >
> > > Further I would suggest to split up the SMOKE and the Qyoto part. I'd
> > > do the same for QtRuby. There are now more than three projects that
> > > make use of SMOKE, so it's unnecessary that every project compiles the
> > > library again.
> >
> > They shouldn't all be compiling it if it's already compiled should they?
>
> If you just work with the kdebindings from SVN, that is true, but consider
> a user who need qt4-qtruby and compiled it, together with SMOKE. Now he
> comes across a project which uses Qyoto, so he downloads qyoto and again
> SMOKE is compiled and installed. Then, for whatever reason, he needs PerlQt
> and there is again SMOKE compiled and installed...
> There is no check in the CMakeLists.txt whether there is already a SMOKE
> library, so it will always be compiled. Also the additional sources just
> increases the size of our releases, so why not just split it up?

I'd be very interested in this too, from a PerlQt standpoint, since building 
the release RPMs is problematic at present since QtRuby, Qyoto, and PerlQt 
all generate libsmoke.

-- 
Gary L. Greene, Jr.
Sent from: uriel
 10:18:29 up 8 days, 15:49,  8 users,  load average: 1.10, 0.65, 0.52
=========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
 See www.tolharadys.net and www.kde.org for more information
=========================================================================

Please avoid sending me Word or PowerPoint attachments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20070602/8fcea2de/attachment.sig>