matthias at nlinux.org
Tue Nov 10 16:02:15 CET 2009
On Mon, 9 Nov 2009 23:41:56 +0100, Den Jean <Den.Jean at telenet.be> wrote:
> 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
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
> 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
> 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
> 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
> 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
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
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
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
> But everyone is free
> 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
More information about the Qt