Cross compiling Qt and dealing with teams

Let me share some notes on how Embedded Linux programming can be, if you decide the war/pain is over. We do this by looking at the desktop build and then look at the tons of stuff that you need for embedded programming.

Desktop

$ pkg-config --cflags libpng12
...
$ qmake && make
...


Embedded
$ . /usr/local/angstrom/arm/environment
$ pkg-config --cflags libpng12..
...
$ qmake-qt4 && make


Where is the difference?
There is little, you just use a cross compiler. The GNU/Linux Toolchain is prepared for cross compilation, pkg-config works with cross compilation.

What if I want different options
You can decide to use different -mtune and -march values, or you can easily regenerate the SDK targeting a different CPU architecture or just the instruction set level of it.

How is this possible
One creates a level of abstraction. The question is why do you want to suffer and don't use the abstraction known from the desktop? The above is given to you by the Yocto/OpenEmbedded and details can be found in the OpenEmbedded Manual. Read here for more details on creating a Qt Toolchain/SDK and using it.

But I want to recompile Qt
Maybe you want to change the qconfig.h, or you have a bug in Qt where you want to test things more interactively. You could either do this in the build directory of Qt of Yocto/OpenEmbedded but then again the created SDK contains all the dependencies for building Qt. All that is missing is the generic qmake spec (that takes its values from the environment) that would need to be copied into mkspecs.

But my application needs libpainful-to-build
The SDK is deployed from header files of packages, you can install more -dev packages into your toolchain. If you use any of armv4t, armv5te, armv6, armv6-nofp, armv7, armv7a, ... chances are high that there is already a build for your machine...

So why is it so painful?
I really don't know, tell me.

Going to the Qt Contributors' Summit

I will leave Reykjavik around midnight, arrive in the early morning in Berlin and then try to get to the venue. This means I will most likely miss the keynotes but should be there by lunch time.

Besides being interested in technical topics like the networking stack, signals for Qt5, I think I will try to focus on the license part of the contribution model. With recent events like Lodys going after individual developers I wonder if there is something Nokia can do to protect individual developers that acted in good faith.

Calligra Flow

Currently I am mostly working on (FreeSoftware) GSM networks, adding software probes, monitors, filtering and patching of certain messages. With any complex system this is spanning across multiple applications, multiple hosts.

Because we collectively know that a picture is worth a thousand words my technical documentation should have a picture, showing the computers, their IPs, some details of how the messages flow and such. Doing this kind of work with Free Software is still a lot harder than it should be.

Currently I am getting the job done with dia, the Cisco stencils are great, many other parts (printing, exporting, scaling, text editing) are not as great and this is where Calligra Flow enters the picture. I compiled a version some months ago and there were almost no stencils, printing was broken...

Yesterday I compiled a newer version of Calligra and there is some very nice progress with Flow, printing does work, saving did work too (no crashes), there are a tons stencils. So thanks a lot for the progress and I will try again in some months.