[Qt] Packaging

[Matthias Klumpp]

On Mon, 9 Nov 2009 23:41:56 +0100, Den Jean <Den.Jean at telenet.be> wrote:
> Hi,
> 
> some Lazarus users probably would 
> like that packages are available 
> for the Qt4 Binding.
Yes. And packages are already available, but they're not in Debian, which
prevents compiling LCL-Qt4 applications on Debian.

> I normally only use a rpm based distro. 
> I already do an effort by creating binaries for 
> Mac and Win (platforms I do not use)
> 
> If people want to improve, they can look into 
> creating a qmake project, that could normalize the 
> building process and create packages.
> I have other priorities than creating packages for debian.
You should not create Debian packages. (This is what I do) I package
applications, the Debian developers approve them and allow upload to the
repositories. They decide, if a package gets accepted.
I got this comment on the sources:
 The build system looks like it is a buildd killer. It basically builds
 all files at once, instead of build all files and then link them
 together.
It would be nice, if someone could fix this so the package gets accepted.
(I have no experience how to create a qmake-file. And if I had, the changes
I would make have to be forwarded to upstream and be included in the
official sources)

> Makefiles just serve to finally create calls to gcc,
> these calls I wrote by hand (there was no qmake in qt2)
> to more easily configure which Qt to use on the system. 
>   - 2 different Qt's on a system: 
> 	The system Qt used to be a Qt3 not so long ago (Debian stable is still
> 	qt3/kde3)
>         or an old unwanted Qt4 (eg Qt 4.0 and you wanted Qt 4.4) 
>   - cross compiling
> The makefile would just pickup the wrong one. But for distro 
> packaging, the system t is ofcourse the target Qt. 
> Both methods can coexist.
Create both  would fix this.

> I would propose to store the rpm and deb packages somewhere (fpc
website?),
> most distros allow the addition of package sources. 
>   - one for latest stable lazarus in a stable source and 
>   - an often refreshed one in a testing/cooker package source
I can send you Debian packages for AMD64 and X86 if you want. Those
packages work great. (but because of the issues it is not clear if they
will be accepted for Debian)

> The binding source is created by scripts, with many manual steps. 
> A Qt binding is actually always alot of manual work (defining 
> solutions to every exception, just read the so called typedef 
> system of QtJambi or a kalyptus generator. If one day I 
> have too much time, I could start again from scratch,
> use e.g. parts of the QtJambi project that is available now,
> and publish everything. Now I do not even find
> time to clean up everything and publish it or
> make a nicer website. Everyone points at smoke instead of 
> QtJambi, but after so many years, smoke is still
> undocumented. This is one of the reasons mentioned
> by PySide developers to not use smoke. I started many years ago 
> when smoke info was even more scarce. 

> Because a debian maintainer refuses to include the FPC Qt binding because
> it
> is not based on smoke, I will not change it to smoke.
I don't think the Debian dev asked you to use SMOKE. He said he likes Smoke
more than the manual way of creating bindings. (It seems he is a Smoke
developer)
Could you please give an answer to this statement?

 The sources seem to contain many autogenerated files with moc. these 
 should be redone on build.

 How are the bindings done? By manually writing each wrapper class or by
 some 'secret script' that helps?

If you use a script but do many manual changes, I would answer this script
cannot be included, because it only helps with manuel writing of the
wrapper classes.

 It looks like the qreal handling is too fragile, but might be just
 enough to make it work on debian, and it seems to assume
 that all people using Qt on arm uses 'qtopia'. (qtopia doesn't exist
 anymore)

Well, this is something I know nothing about ;-P

 And wouldn't it make more sense to create different bindings for each qt
 module? That's what the python, c#, ruby, php, lua, ... bindings are
 doing.


> But everyone is free
> to 
> create one. I guess it would be more interesting if you would spend time
> in creating packages. 
The packaging is fine but ONE developer looked at the code. So I had to ask
you about these issues to reply on this criticism and to get the package
accepted.

Best regards
  Matthias Klumpp