What always seems to happen from time to time in support is that you can go a few weeks without getting any cases on a particular issue, only to come across a group of them all at the same time. They are like buses in that respect, you wait for ages for one to turn up and then two turn up right after each other. Last week we had a couple of obscure qmake bugs turn up which required a fair bit of debugging and investigation to try and pinpoint the cause of them.
The qmake tool is a useful and powerful makefile/project file generator, which can be used for non-Qt projects too. However, the problem is that the documentation is, unfortunately, lacking in places and the sheer combination of options and features available can make it difficult to debug it when things go wrong and also to know how to achieve certain things.
Luckily ,in the cases that we encountered I was able to apply my rather detailed knowledge of how qmake works behind the scenes (which I also learnt more of when implementing support for generating XCode 4 projects). The main tool that is available is checking the debug output from qmake itself. Luckily, this feature is already built in so all you need to do is use the –d option when running qmake to get some debug output. You can specify this up to four times to get more and more debug from qmake so the first thing I always do is to run this:
qmake –d –d –d –d 2>debug.txt
This gives me a good overview of what qmake is doing at all points and what is assigned to what variable. Unfortunately for me, in these cases nothing showed up as wrong, but it did verify that qmake was doing what was generally expected of it. Therefore ,the problem had to be coming from somewhere else but related to qmake, either the pro file or one of the many feature files (prf files).
In the case of a missing RC_FILE entry – https://bugreports.qt.nokia.com/browse/QTBUG-22545 – what I had to do was to keep trimming down the pro file until I could pinpoint what exactly was the trigger of the problem as I could not reproduce it in a smaller case. What I had to do to help here was to copy the include()’d pri/pro files so that they stood literally in the main pro file to make it easier to take bits out. Eventually, I was able to pinpoint it to the removal of a CONFIG entry so this made it easier for me to reproduce in a smaller example.
This then made it easier to figure out how to fix it, and after some debugging of the code itself, I was able to fix it. The patch is already submitted back to Nokia and if any customer needs it then please send in a support request and we will send you the patch. It should be included in Qt 4.7.5 and Qt 4.8.0.
So, if you encounter a problem with qmake then at least you can see what the debug output is giving you, and if you send a support request to Qt Commercial Support that refers to a problem in qmake, then sending the output from the qmake command above will certainly help speed up the process of us looking into it alongside your pro file/pri files.
PS: In case you missed the tweet from @QtCommercial (follow us on Twitter!), Qt Commercial Support supplied 71% of the bugs reported in October via the Qt Commercial Customer Portal with a workaround and/or a patch to resolve the issue.