Hello, I only very recently learned about the Qt embedded series that there is for Linux. This is, so I understood it, basically the whole functionality of Qt but without the dependency on X. To me this sounds very worthwhile to have also as (separate) Debian packages since highly attractive to the embedded world.
>From my look at the documentation I read between the lines somehow that there is no second source tree. So I just took your qt-x11 source package via "apt-get source" and could execute yes | ./configure --embedded=x86_64 -opensource \ -qt-gfx-linuxfb -qt-gfx-qvfb -qt-gfx-vnc \ -qt-mouse-qvfb -qt-mouse-linuxinput # other options to experiment with: # -qconfig qpe -depths 4,16,24 -shared #-thread -system-jpeg -system-libpng -system-zlib -vnc -no-xft make sudo mkdir /usr/local/Trolltech sudo chown $(whoami) /usr/local/Trolltech make install on it with not difficulties (except it having filled my partition _twice_ with its 5+ GB and it taking 10+ hours on my laptop). This is nice. There was just this issue during the build g++ -c -pipe -m64 -g -fno-exceptions -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_SHARED -I../../mkspecs/qws/linux-x86_64-g++ -I. -I../../include/QtCore -I../../include/QtNetwork -I../../include/QtGui -I../../include -I../../src/gui/embedded -I../shared/deviceskin -I.uic/release-shared-emb-x86_64 -I.moc/release-shared-emb-x86_64 -o .obj/release-shared-emb-x86_64/qvfbshmem.o qvfbshmem.cpp qvfbshmem.cpp:65:2: error: #error qvfb must be compiled with the Qt for X11 package make[2]: *** [.obj/release-shared-emb-x86_64/qvfbshmem.o] Error 1 make[2]: Leaving directory `/home/moeller/src/qt4-x11-4.6.3/tools/qvfb' make[1]: *** [sub-qvfb-make_default-ordered] Error 2 make[1]: Leaving directory `/home/moeller/src/qt4-x11-4.6.3/tools' make: *** [sub-tools-make_default-ordered] Error 2 which let me comment out anything qvfb-ish in Makefile and tools/Makefile . I somehow presume this to be a bug of the Makefile generation under the -embedded conditions . qvfb is the environment in which developers can test their apps linked against the embedded libraries ... wich makes good sense to have linked against the x11 project's libs. To start qvfb -height 600 -width 400 & /usr/local/Trolltech/QtEmbedded-4.6.3/bin/qtdemo -qws -display QVFb:0 which is really amazing. I works on the Linux console, too. Would it be reasonable to possibly perform this second build as an extension of your regular qt4-x11 package (which would then somehow have a wrong name, but who cares) with the --embedded flag set. What comes to mind is a debian/rules-embedded that could be executed from debian/rules. I admit not to see for the moment how this could be achieved without a second build directory. I found this setting of OBJECT_DIR http://stackoverflow.com/questions/1741877/qt-and-qmake-build-dir but this would mean the qmake would need to get together with the build, which all seems somewhat undebianish. But this is still better than shipping the same source code twice in Debian, I think. Another posibility would be to have a qt-src package that both the X11 and the embedded flavours needs as a build requirement. Just thinking loudly. I still think adding the embedded variant would be outermost beneficial for our distribution, at least so in the longer run. It will e.g. attract more developers, who can then be certain to have the same version of Qt on their desktop and for their mini-devices. And fiddling with small devices will attract more people caring for optimisations in terms of disk space, kernels and boot process, from which also the regular Debian install should profit - if not from the direct work then from the people being around. Hoping for a positive reply, with many thanks and regards Steffen -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk