Customized build (problems, bugs, patches, licencing issues...)

[Domagoj Saric]

Hi everyone, my first post here

As of recently I have to use Qt for GUI development so my encounter with the latest available version (4.52 / 2009.03.01) was also my first real encounter with Qt.

(the 'full' environment is as follows: Qt 4.52 open source, MSVC++ 9.0 SP1, WinXP Pro SP3)

One of the first things I set out to do was to customize the build (mainly to cut down the humungous size of the produced binaries). For this task I found the following means:
- the official configure.exe options
- the 'almost-official-but-sort-of-hidden' (?) qfeatures.h configuration header
- the rest of the undocumented QT_NO_* configuration macros that can be found throughout the source files.

In all of the 'means' I found options that were broken and/or incorrect (of course most of the issues were with the usage unofficial configuration options/'tricks'):
- the configure -qtnamespace option is broken (the build fails when you try to build Qt within a namespace)
- even if the above could be fixed one could still not build the library within a "Qt" namespace (the obious choice) as someone has made the 'smart' decision to create a "Qt" namespace within Qt itself (thus producing ambiguities)
- it is not clearly documented how to 'cleanly' build only certain libraries (e.g. only core and gui, i have thus resorted to manually calling nmake from the folder of the desired libraries)
- there is no separate build for libraries to be used for development and redistribution and for libraries (DLLs) used by the tools (assistant, designer etc...) - this creates a problem when you wish to remove unnecessary functionality from the libraries that are unnecessary for your own needs but are necessary for the tools...because of that i had to make the script that builds Qt in two passes: the first time it builds the tools and the libraries only in release shared mode with all the default functionality (which then get stored in the bin folder) and then in the second pass only the libraries are built in all the desired flavours and with only the options I actually need (which then get stored in the lib folder)
- when using certain QT_NO_* configuration macros in the qfeatures.h file they must also be manually passed as defines to moc.exe in the MOC phase otherwise the build fails in the phase of compiling the MOC generated .cpp files (these inclulde QT_NO_HTTP, QT_NO_LOCALSERVER, QT_NO_WIZARD, QT_NO_IM, QT_NO_DIAL, QT_NO_FILESYSTEMWATCHER, QT_NO_THREAD, QT_NO_BUTTONGROUP, QT_NO_SPLITTER, QT_NO_STACKEDWIDGET, QT_NO_TOOLBUTTON, QT_NO_COMPLETER, QT_NO_REGEXP, QT_NO_SCROLLAREA, QT_NO_SCROLLBAR, QT_NO_ITEMVIEWS and QT_NO_SLIDER)
- the MSVC++ qmake.conf files use sub-optimal compiler switches (I've included better ones)
- the MSVC++ 8.0 and 9.0 qmake.conf files also have incorrect RTTI-off and LTCG-for-static-libs switches (these are also included in the patches)
- the build system does not allow you to configure the CRT linking policy (defaults to dynamic) without qmake.conf 'hackery'
- in general there were a lot of 'bugs' throught the Qt sources that became apparent only when customizing the build in the above mentioned ways, I have patched most of those encountered and am attaching the patches with this post. Most of the patches deal with the following issues:
- - _ASCII/non _UNICODE build bugs (mixing wchar_t and TCHAR, TCHAR and
SomeWin32FunctionW() ...)
- - assuming that _MSC_VER >= 1400 implies that __STDC_WANT_SECURE_LIB__ is also defined
- - incorrect order/coupling of begin/end namespace, ifndef/endif and/or include
statements
- - missing ifndef/endif statements
- - defining _WIN32_WINNT without checking if it is already defined.

I was also 'pretty annoyed' by the fact that QFileDialog (among other things) >requires< threading functionality (QT_NO_THREAD must not be defined) which is IMO a too big requirement for a 'simple' dialog (especially considering that not defining QT_NO_THREAD considerably bloats all/most other parts of Qt as threading functionality then gets used by many other classes, and of course considering that the OS provides a direct native implementation of a file/folder dialog). For this reason the patches also include my lame unsuccesfull '10 minute' attempt to make the file dialog work without requiring threads and regexes (the dialog appears but is not quite fully functional ).

Additionaly the following QT_NO_* macros seem to be broken (the build fails) and I was unable to fix it: QT_NO_QOBJECT (obiously ), QT_NO_CONTEXTMENU, QT_NO_GEOM_VARIANT, QT_NO_FSFILEENGINE.

The original qfeatures.h file seems to imply that IMAGEFORMAT_XPM requires TEXTSTREAM but it builds fine without it.

The patches archive retains the original folder structure but only contains the changed files along with the original ones (that have .original appended to the filename) thus providing for easier patching (simply copy and overwrite), comparison (with tools like BeyondCompare) to see the actual changes and diff/patch file generation. The archive can be downloaded here: http://rapidshare.com/files/287303310/patches.rar (I could not attach it here because it is a ~1.5MB RAR archive).

Finaly, what are the licencing implications of patches like these...I suppose the modified sources have to redistributed, but what about qmake.conf files and the qfeatures.h file...do they fit in the same category and need to be redestributed?


ps. I am not sure whether this was actually the correct forum as the contents of the post are mixed (in the sense that they could also fit in the "Programming" forum). I was also puzzled by the lack of official Qt/Trolltech forums (the ones found here http://labs.trolltech.com/forums do look amateurish/'internal'): what would be the right approach to have these patches looked at and maybe included in the next Qt release...send a link to this thread through the official bug report form?.

pps. Is there a way to delete an account here on Qt Center (I created two by mistake)..?

[squidge]

There do seem to be a number of QT_NO_* definitions that can't actually be used. I know I tried to use some of the definitions you have stated, along with others such as QT_NO_COMPRESS, but it doesn't work so well. Some files don't bother to check for that definition and just use the functions anyway (causing undefined symbol errors), and others have #ifdef/#endif checks around the function, but the bracket balance is wrong if the code inside is not compiled.

Have you also noticed how QFileDialog depends on qCompleter? In one place, the references are surrounded by #ifndef QT_NO_COMPLETER, whilst further down other references exist that don't bother with such directives.

I suppose this is what happens when you have a large development group attempting to maintain such a big project, but you would still expect them to actually make sure the definitions still work every so often, although you would need some kind of automated setup as checking every single combination would take a very long time, and certainly drive a person insane!

Thanks for your patches however, I'll be sure to check them out later.

[rix]

Thanks for your work ! I also started working on similar patches but stopped (lack of time...).

what would be the right approach to have these patches looked at and maybe included in the next Qt release...

I would suggest you to have a look at http://qt.gitorious.org/qt/pages/QtC...tionGuidelines .