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

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

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 
-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 
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 
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 
libraries ... wich makes good sense to have linked against the x11 project's 

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
but this would mean the qmake would need to get together with the build, which 
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 
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 
who can then be certain to have the same version of Qt on their desktop and for 
mini-devices. And fiddling with small devices will attract more people caring 
optimisations in terms of disk space, kernels and boot process, from which also 
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



Reply via email to