Take a look at this wiki article [developer.qt.nokia.com]

Thank you very much for the reply. Will look up in the article.

No problem. That article series is still not finished (nor will it ever be). I’ll try to add some more to it in the near future. Feel free to come back with more questions as they occur to you and we’ll see what we can do to help.

Thanks for the assistance. I am in need of another clarification.

There are all these options we can specify with ./configure ( e.g. -dbus, -stl ) as specified here:

http://doc.qt.nokia.com/4.7-snapshot/configure-options.html

There is also this document here about something called qconfig:

http://doc.qt.nokia.com/latest/fine-tuning-features.html

So, are these ways to turning on/off features mutually exclusive? i.e. if we specify -qconfig in the ./configure command line, we should not specify anything else related to the features in the same command line?

Also, the same fine tuning document refers to what are no-feature{something} options, which the first document does not talk about.

Am I the only one to be confused?

As a rule of thumb, start out simple and then change things a little at a time if you find you need a feature or really want to remove a feature.

Using the qconfig tool can be dangerous. It does not enforce dependencies between features (as far as I am aware) so you can easily shoot yourself in the foot. If you do choose to use the qconfig tool then you have to pass in the created config file to the Qt configure tool like this:

where myfile is the saved output from qconfig.

In any case it is unlikely that your embedded app will use all the facilities of Qt and so you can get away with deploying only a subset of the QT libs to your target device. For example if you do not use the QtSql module in your app there is no need to copy across libQtSql.so to your device.

I woudl suggest to get your app working using only a basic configure command first and only then consider using the qconfig tool if you find that you are severely space constrained on your target device.

I did start out simple and the basic configuration works well. But, I really need the size down, since I work in an environment with limited resources, so I have a real need to strip whatever is unnecessary.

I had a bit of trouble with the documentation so far. The -fast, from what I read, was intended to leave out compiling the demos and examples, if I read right. But that didn’t work. Then, I read up somewhere about -nomake demos and -nomake examples. I tried those options, and they do work right. What baffles me is the configure documentation makes no mention about these flags. It’s frustrating and dangerous to be trying out things that are not really documented.

I agree that the help for the configure script is missing some stuff and is not the clearest. If you find shortcomings and want to help fix them for others you can do so by getting yourself an account at gitorious [qt.gitorious.org] and submitting a merge request for your changes.

For info the -fast option just makes the initial configuration stage faster because it only generates the top-level Makefiles rather than Makefiles for all the sub-dirs. The sub-dir Makefiles get generated during the actual compilation stage by special rules that call qmake first in each sub-dir.

What modules do you definitely need? What features within them are you using? What are your space constraints?

Hi ZapB,

appreciate your helpful answers. With your help, am slowly able to get around some of the confusions. I’ll look into registering with gitorious, thanks for the tip.

The -fast option is clear now. For my production build I’ll use the -nomake demos and -nomake examples options, because I have no need for them.

I have a simple UI, mostly text and a few indicators and icons on the screen. That’s about it. No need for fancy windowing stuff and things like that. So , QWidget , QLayout stuff, XML handling ,keyboard and graphic handling is all am after. No need for all the fancy dialog stuff.

Ideally I would like to have the binary size less than 1.5 – 2 MB. Right now, it is coming at around 13 MB which seems a too much.

This is all the ./configure options am using:

-embedded arm \ -static \ -release \ -fast \ -nomake demos \ -nomake examples \ -no-largefile \ -no-accessibility \ -no-stl \ -system-sqlite \ -no-qt3support \ -no-xmlpatterns \ -no-multimedia \ -no-audio-backend \ -no-phonon \ -no-phonon-backend \ -no-svg \ -no-webkit \ -no-javascript-jit \ -no-script \ -no-scripttools \ -no-declarative \ -no-declarative-debug \ -system-zlib \ -no-libtiff \ -no-libmng \ -no-openssl \ -no-nis \ -no-cups \ -no-opengl \ -no-gfx-transformed \ -no-gfx-qvfb \ -no-gfx-vnc \ -no-gfx-multiscreen \ -no-gfx-directfb \ -no-gfx-qnx \ -no-kbd-tty \ -no-kbd-qvfb \ -no-kbd-qnx \ -no-mouse-pc \ -no-mouse-linuxtp \ -no-mouse-linuxinput \ -no-mouse-tslib \ -no-mouse-qvfb \ -no-mouse-qnx \

Is a 2 MB size too optimistic a size ?

I will have to try a small build myself as I can’t recall what size I got the build down to before.

In the meantime, another option you should consider is that of building Qt as a static library. That way at link time, the linker will only include the parts of Qt that you are actually calling. As a side benefit it also removes the relocations performed by the runtime linker at application startup so your app will start faster.

But using Qt as static lib must be clearified with the license you are using.
Afaik, with LGPL, static builds are not allowed…
Only with commercial and GPL I think.

IANAL but I was under the impression that you could use a static build under the LGPL license as long as you provide a way of relinking your app with a newer version of Qt. Not saying that it is easy. And for all I know the OP could be using a commercial license. Are you?

ZapB wrote:

IANAL but I was under the impression that you could use a static build under the LGPL license as long as you provide a way of relinking your app with a newer version of Qt. Not saying that it is easy.

Thanks for the replies all. I wasn’t aware of the shared versus static complication. So appreciate your bringing it up. I don’t have any idea of the legal issues, so will leave it to the respective guys to figure it out. At the moment, I would at least like to have both static and shared linking options figured out and have a feel of the minimum sizes I can get in each case. Those numbers might also drive what licensing options we might consider. Since there is just one QT app running on our device, there is really no “need” for the shared option, except if that need is enforced upon by the licensing restrictions.