No subject

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