Den Jean wrote 5 lines
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.
Show quoted text 8 lines
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)
Show quoted text 11 lines
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)
Show quoted text 17 lines
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
