Hello!
I try to get the libqt4intf into Debian, so that FPC-Qt4 applications can be build for Debian repositories.
I got the following comment of Sune Vuorela, a maintainer of qt, kde, including kde and qt bindings for various
languages.
(I removed some parts of his mail, which only affect my packageing)

---------
Subject: Re: RFS: libqtintf4
Date: Sat, 7 Nov 2009 11:59:10 +0000 (UTC)
From: Sune Vuorela

[...]

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

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)

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.

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.

I'm not sure I like this way of creating qt bindings, I_think doing what the kdebindigs people, by using the 'smoke' intermediate library is a better way ahead.

I'm not interested in pascal, so I won't sponsor this. This is a first list of comments from some Qt person ;)

/Sune
- maintainer of qt, kde, including kde and qt bindings for various languages.
--------
Could you please clarify those issues? Maybe use a ordinary Configure/CMake system and maybe split the lib into several different modules? Thanks for your comments and best regards
Matthias Klumpp

2009/11/7 Matthias Klumpp

I have to agree with this point that it might be good idea. Maybe not for each module (rather group of modules) but still. For example why would I need code for WebKit if I don't use it in my Qt application?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/qt/attachments/20091107/ca0017cf/attachment.html>

So, 'smoke' can do C bindings ?
Anyway, I can agree that it would be nice to have separated bindings for each qt lib eg. gui, non-gui, network, webkit etc .. but I'm happy with current one because:
1.It's the only bindings which have.
2.It works, thanks to Den.

So, I think that only person who can help you/us is Den.

zeljko

zeljko wrote

So, 'smoke' can do C bindings ?

This is what I grot from Pau Garcia:

Off-topic but still: yes, SMOKE does work on those platforms.

It'd be nice if these bindings were generated by SMOKE because that would make its maintenance easier both for upstream and for you.

SMOKE does a very good job, it's faster than the official bindings Nokia is providing (QtScript, PySide). Take a look at http://www.kdedevelopers.org/blog/89 (and
http://www.kdedevelopers.org/node/4079 in particular).

So, why do we not use SMOKE? Den, where are you? :-P Cheers
Matthias

Matthias Klumpp wrote

Off-topic but still: yes, SMOKE does work on those platforms.

was not the case when the pascal binding was created.

It'd be nice if these bindings were generated by SMOKE because that would make its maintenance easier both for upstream and for you.

big ? mark

SMOKE does a very good job,

you need to have written a binding to understand
why so few bindings used smoke at that time

it's faster than the official bindings

fast enough for a scripting language,
it would be sad for a fast static language like FPC.

Why did PyQt, PySide,QtJambi, QtAda,QtC,QtScript .. etc not use smoke ?

I have seen many Qt bindings come and go. PerlQt3 used smoke, why was it that years after the Qt4.0 release there was no PerlQt4 :-)

But a Pascal Smoke Qt 4 binding would be complementary, though my binding fulfills its goals, a smoke binding would be way more complete. I am looking forward to see your results (and comment on the quality ;-) )

Understand that the other bindings try to provide a GUI library to their language, whilst Lazarus already has one. Providing Lazarus with a Qt backend (widgetset) is something entirely different.

regards,

Den Jean

-------- Original Message --------
Subject: Re: RFS: libqtintf4
Date: Sat, 7 Nov 2009 11:59:10 +0000 (UTC)
From: Sune Vuorela

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?

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)

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.

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.

I'm not sure I like this way of creating qt bindings, I_think doing what the kdebindigs people, by using the 'smoke' intermediate library is a better way ahead.

I'm not interested in pascal, so I won't sponsor this. This is a first list of comments from some Qt person ;)

What do you say to this, Den? The most important thing which blocks the Debian inclusion is the missing build system and the missing script which autogenerates the moc files. I don't know what "qreal handling" is, but could you look at this? :-P
Thank you for your comment, I will FWD it to clearify why SMOKE is not used.
Regards
Matthias

Matthias Klumpp wrote

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.

FYI:

I am working on a build system.

Instead of a very short compile script with a single gcc call, I now have a qmake project file of 647 lines and a corresponding Makefile of 3384 lines.
Calling Make results in countless gcc calls.

Instead of a compile time of only 13secs,
compilation now takes 11 minutes using 'make'
or 5 minutes with 'make -j 6'

Separating code in several files (.h/.cpp) and be able to compile files individually and link together, has advantages when you manually edit some files. Then only the edited files need to be recompiled. As the files are not manually created, this advantage is pointless.

As the compile time is unacceptable, I will revert this change and revert to building all may look as not
doing it the proper way, but the explanation is that the files are generated and not manually edited.

I will keep the qmake project file, as package builders are more familiar with that.

The current qmake project file is only
tested on linux (lazarus compiles and runs fine)

So I tried, but it is unacceptable, but I hope the qmake project file will facilitate the creation of packages.

temporarily available at:
http://users.telenet.be/Jan.Van.hijfte/qtforfpc/qt4intf_qmake.tar.gz

Instructions:
========
untar
cd qt4intf_qmake/

  qmake
  // generates Makefile
  // requires libqt4-devel package
  // run qmake -query to see which Qt version is used (and where it resides).
  make    // compiles c++ code, so go grab a coffee

kind regards,

Den Jean

Hello Den,

Since you are working on this, what about splitting the bindings?

Currently LCL-Qt applications need QWebPage, QNetworkXXX, etc, which are not used by it.

A simple split in 2 parts, one with some basic packages which LCL uses and another with extra packages would solve the problem.

thanks,

I cannot agree with such splitting - it's just workaround. If there's a need to split qt bindings, then it should be splitted in manner of qt libs.
1.qtcore (so it can be used for console apps only) 2.qtgui (gui components)
3.qtnetwork (network components)
4.qtwebkit (webkit)

In this case lcl-qt should use qtcore + qtgui

zeljko

On Wed, 16 Dec 2009 22:56:21 +0100, Den Jean wrote: [...]

11 minutes? Wow! Then it's better to use the current version... I just need someone to upload the Debian package into the repositories of Debian. I will ping my request of adding it cause I got no response from any maintainer.
It would be great if the Lazarus/FPC Debian maintainers could advocate the Qt4-Package.
Thanks for your work!
Regards

Matthias

Agreed. Such thing would be welcomed on Windows. On Linux Qt comes with system anyway (usually). on Windows it doesn't. And atm simple Lazarus application compiled with Qt requires some set of Qt dlls

Best regards
Marcin D?bicki

2009/12/17 zeljko :

Hi again!
There are some steps which need to be done to get this package accepted into Debian.
I have to use the qmake project for Debian as explained below. (I forward Sunes E-Mail from Debian Mentors)
--------------------------------------
The way it is built, it takes around 1G of memory to build. This *needs* to be fixed. it might be a small lib, but the way it is built is just plain wrong. Especially since this can be easily fixed.

The moc output files *must* be regenerated on build, else you end up with issues like:

In file included from qtpas.cpp:370:
lib/hooks//qwebsettings.cpp_mk:14:2: error: #error "This file was generated using the moc from 4.5.2. It"
lib/hooks//qwebsettings.cpp_mk:15:2: error: #error "cannot be used with the include files from this version of Qt."
lib/hooks//qwebsettings.cpp_mk:16:2: error: #error "(The moc has changed too much.)"

from next Qt upload.

and the build script *needs* to be fixed so that it actually fails when build fails.

dpatch apply-all
applying patch 01_buildscript.patch to ./ ... ok.
bash /tmp/libqtintf4-1.72Qt4.5.2/compile_lib.sh
Please Modify location of Qt4 in this script
touch build-stamp
fakeroot debian/rules binary
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
dh_install
dh_install: libqt4intf5 missing files (libqt4intf.so.*), aborting

/Sune
--------------------------------------
Could those issues be fixed in new minor release?
Thanks for all!
Matthias Klumpp

Oh, sorry I haven't seen that everything is already done in the qmake-version of the project.
I will re-package the binding and forward it to Debian again. Could you please add the binding version to the source tarball name like it is done with the one-buildscript ones?
Debian packages can fetch new upstream versions automatically if the upstream source tarball includes the upstream version name. Thank you for your help again!
Matthias Klumpp

Matthias Klumpp wrote

Could you please add the binding version to the source tarball name like it is done with the one-buildscript ones?

This was not a release. I have not looked into Windows and Osx support. The next release will contain as usual a version tag, currently the release scripts are broken due to the qmake changes, so it was packed manually.

I mean not an 'official' release, but maybe a Linux-only release for use with RPM/DEB packages.