RFS: libqtintf4

[Matthias Klumpp]

Dear mentors,

I am looking for a sponsor for my package "libqtintf4".

* Package name    : libqtintf4
  Version         : 1.72Qt4.5.2-1
  Upstream Author : (C) 2009 Jan Van Hijfte
* URL             :
http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html
* License         : GPL
  Section         : libs

It builds these binary packages:
libqt4intf-dev - Qt4 interface bindings
libqt4intf5 - Qt4 interface bindings

The package appears to be lintian clean.

The upload would fix these bugs: 554177

My motivation for maintaining this package is that I use the library by
myself in many projects and a lot of FPC-Qt4 projects depend on it. I would
love to see this in Debian.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libqtintf4
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/libqtintf4/libqtintf4_1.72Qt4.5.2-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Matthias Klumpp


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sune Vuorela-2]

On 2009-11-07, Matthias Klumpp <matthias@...> wrote:
> http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html
> * License         : GPL

Looks like lgpl

> It builds these binary packages:
> libqt4intf-dev - Qt4 interface bindings
> libqt4intf5 - Qt4 interface bindings

For which language?

> - dget
> http://mentors.debian.net/debian/pool/main/l/libqtintf4/libqtintf4_1.72Qt4.5.2-1.dsc

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 ;)

/Sune
 - maintainer of qt, kde, including kde and qt bindings for various
   languages.


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthias Klumpp]

On Sat, 7 Nov 2009 11:59:10 +0000 (UTC), Sune Vuorela <nospam@...>
wrote:

> Looks like lgpl
Oops, misstyped! The debian/copyright file is correct

>> It builds these binary packages:
>> libqt4intf-dev - Qt4 interface bindings
>> libqt4intf5 - Qt4 interface bindings
>
> For which language?

For Pascal, but a few other languages use it under Windows. (but just
experimental)

>> - dget
>>
http://mentors.debian.net/debian/pool/main/l/libqtintf4/libqtintf4_1.72Qt4.5.2-1.dsc
>
> The sources seem to contain many autogenerated files with moc. these
> should be redone on build.
Okay, I will fix that.

> How are the bindings done? By manually writing each wrapper class or by
> some 'secret script' that helps?
Seems it is all written manually.

> 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)
I'm not a Qt-Developer (I never used Qt in C++), but I can forward your
mail to the libqt4intf-developers. Maybe they can do something.

> 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.
Maybe... I forward this mail to the module devs.
> 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.
Yes, this is really a strange thing - but it works.

> 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.
The libqt4intf is also available for Windows and MacOS-X. I dont't think
Smoke works on those platforms.

> I'm not interested in pascal, so I won't sponsor this. This is a first
> list of comments from some Qt person ;)
Do you have to be interested in a package to upload it? I think the
comments will help upstream a lot to make this package better.

> /Sune
>  - maintainer of qt, kde, including kde and qt bindings for various
>    languages.
So you know a lot about this :-P

Best regards
   Matthias Klumpp


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Pau Garcia i Quiles]

On Sat, Nov 7, 2009 at 8:37 PM, Matthias Klumpp <matthias@...> wrote:

>> 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.
> The libqt4intf is also available for Windows and MacOS-X. I dont't think
> Smoke works on those platforms.

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).

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthias Klumpp]

Hello again!
I got the following reply on your comments for the libqt4intf interface
library from Den Jean, a Qt4-Intf developer:

-------- Original Message --------
From: Den Jean <Den.Jean@...>
To: Items specific to the Qt widget set <qt@...>

On Sunday 8 November  2009 17:22:36 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.

> 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
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
---------------------
So I don't see any blocks for this package. It is also impossible that all
Pascal developer switch to new SMOKE bindings within a week. I still wait
for a comment on the moc-files and the build-script issue. Maybe this can
be fixed for the Debian packaging.
Regards
  Matthias Klumpp


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthias Klumpp]

Hello again!
I got this reply from Den Jean about the sources as statement:

--------------------

[...]

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.

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

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.

[...]

--------------------
He will definitely nor re-write the interface using SMOKE (because it is
undocumented and not necessary. Also many applications depend on the
existing libqt4intf).
I dont's see why this package can not be included into Debian. The only
thing which blocks the inclusion is the lack of a make system like qmake,
right?
If at least one uses this software, it is relevant for Debian, I think.
Maybe they will switch to SMOKE later, but today the interface library is a
fixed standard if you want to create Qt4 applications with FPC. Do you have
comments on packaging?
Kind regards
   Matthias Klumpp


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sune Vuorela-2]

On 2009-11-10, Matthias Klumpp <matthias@...> wrote:
> Makefiles just serve to finally create calls to gcc,

And I  think the way the gcc calls are made requires a amazing amount of
RAM for no apparant reason.

> 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)

Unimportant what's in debian stable for a package targetted unstable.
and erm. talking about Qt2?
Qt2 was released in 1999. last Qt2 release was november 2001.
Qt3 was released in october 2001, last Qt3 code changing release was
march 2007. I'm not sure why this is relevant here.

> The binding source is created by scripts, with many manual steps.

so the shipped 'source' is not actually 'preferred form of
modification'?

> 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.

kalyptus is the old perl tool used for kdebindings, where there now (for
kde4.4 is a newer and better tool) written in c++ using the same parser
as used in kdevelop and others.

> He will definitely nor re-write the interface using SMOKE (because it is
> undocumented and not necessary. Also many applications depend on the
> existing libqt4intf).
> I dont's see why this package can not be included into Debian. The only
> thing which blocks the inclusion is the lack of a make system like qmake,
> right?

The thing that blocks inclusion is a 'interested sponsor'. I currently
maintain a set of bindings, where the smoke based bindings is the one
giving me least grief. And I'm not interested in sponsoring things that
increases my headaches.

> If at least one uses this software, it is relevant for Debian, I think.
> Maybe they will switch to SMOKE later, but today the interface library is a
> fixed standard if you want to create Qt4 applications with FPC. Do you have
> comments on packaging?


I haven't gotten to the packaging yet, because there is two things from
upstream that *needs* to be fixed.
1) The moc gerenated files *needs* to be generated on build, else the
build might break on each new qt version.
2) The build system needs to be done in a way that doesn't kill buildds
when it can be avoided.

Anyways:
Why does it build-depend on libqt4-core ?
Why do you chmod +x the compile_lib script when you use bash to run it
anyways?
How do you make sure the build fails, if the compile_lib script fails?

/Sune


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthias Klumpp]

On Wed, 11 Nov 2009 00:15:18 +0000 (UTC), Sune Vuorela <nospam@...>
wrote:

> [...]
>
> I haven't gotten to the packaging yet, because there is two things from
> upstream that *needs* to be fixed.
> 1) The moc gerenated files *needs* to be generated on build, else the
> build might break on each new qt version.
> 2) The build system needs to be done in a way that doesn't kill buildds
> when it can be avoided.
>
> Anyways:
> Why does it build-depend on libqt4-core ?
> Why do you chmod +x the compile_lib script when you use bash to run it
> anyways?
> How do you make sure the build fails, if the compile_lib script fails?
>
> /Sune

The patch for the build-script also includes "set -e" int the buildscript,
so the package build fails if the build script fails.
The libqt4-core dependency is useless, I removed it. The chmod +x is also
not needed of course, I removed it to within the new upload.
I forwarded the "must haves" to the developers, maybe they'll fix them.
Thanks!
  Matthias Klumpp


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...