[Kde-bindings] A Qyoto pre-release

[Arno Rehn]

Am Freitag, 1. Juni 2007 schrieb David Canar:
> On 6/1/07, Arno Rehn <arno at arnorehn.de> 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. 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.
> > 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.
>
> Good! I didn't follow the int& arg issue so I didn't know qyoto was
> broken but it is good to hear that it works now.
> I haven't had any problems with the generation of the sources from the
> headers are you talking about the process that a perl script does at
> the moment smoke gets compiled?
Yes, the Qyoto sources are generated the same way as the SMOKE sources, with 
the kalyptus tool. The issue is that if you use the same header list for 
Qyoto as for SMOKE, there will be a lot of unnecessary sources generated.

> I'll prepare another "pre-release" package with these things in mind.
> Do any of you know how the private key is handled in an open source
> project? how the mono guys strong sign their assemblies? I know it is
> very simple to strong sign an assembly but I don't know how "private"
> a private key should be in an open source project. Any ideas?
I think we shouldn't include a pre-generated key in the release. We just look 
for sn (the tool for creating a key pair) and let it generate such a key-pair 
just before qt-dotnet.dll is compiled. I'll add that to the CMakeLists.txt 
today.


-- 
Arno Rehn
arno at arnorehn.de