Re: RFS: libqtintf4
On 2009-11-10, Matthias Klumpp <matthias@nlinux.org> 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
Reply to: