On 2009-11-10, Matthias Klumpp <matth...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
