[Kde-bindings] A Qyoto pre-release

[Arno Rehn]

Am Sonntag, 3. Juni 2007 schrieb David Canar:
> On 6/2/07, Arno Rehn <arno at arnorehn.de> wrote:
> > 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.
>
> Ah! that's smart. I didn't think about that option. Is that the way
> mono does it?
Well, I thought twice about it and chose to pre-generate the key. The problem 
is the following: The user generated a key, compiled and installed it. Now, 
for whatever reason, he wants to install Qyoto again. So generates a new key, 
compiles it and installs it again. If the 'old' qt-dotnet.dll wasn' removed 
from the GAC, we now have two identical qt-dotnet.dll's in the GAC, which 
just differ by there signing key. That could actually lead to some chaos, I 
think.
To avoid this, I included a pre-generated key so the old version in the GAC 
will always be overwritten.


-- 
Arno Rehn
arno at arnorehn.de