Changed behaviour in Qt 5 beta 2

So, I’ve taken the time to shift my development target at work to Qt 5 beta 2 (from beta 1). Most things work perfectly, however, qmake has changed its behaviour slightly – in a subtle evil way.

First, some background. I’m building a QML plugin. When building it with beta 2, it no longer loads as it could no longer resolve the vtable for one of my classes.

$ readelf -sW /home/e8johan/work/prf/lamprey/lamprey/lib/liblampreyqml.so | grep UND | grep QmlAudioHardware | c++filt 
    45: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND vtable for QmlAudioHardware
    47: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::nameChanged()
    50: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::volumeChanged()
   288: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND vtable for QmlAudioHardware
   301: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::nameChanged()
   308: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::volumeChanged()

What was this all about? I looked at the source, commit logs, everything – nothing had changed and everything was in place. Inheritance – check, Q_OBJECT macro – check, file listed in HEADERS in the pro-file – check…

Then I started to look at what was actually built. Apparently not the moc

$ find | grep moc | grep qml
./qml-plugin/build/moc
./qml-plugin/build/moc/moc_qml-plugin.cpp
./qml-plugin/build/obj/moc_qml-plugin.o
./qml-bindings/src/build/moc
./qml-bindings/src/build/moc/moc_http_downloader.cpp
./qml-bindings/src/build/obj/moc_http_downloader.o

Since the software I build worked, I simply built it using qmake && make -j5 and then went for a coffee. When doing qmake -recursive I notices a long list of header files that weren’t found:

$ qmake-qt5 -recursive
...
Reading /home/e8johan/work/prf/lamprey/lamprey/qml-bindings/qml-bindings.pro
 Reading /home/e8johan/work/prf/lamprey/lamprey/qml-bindings/src/src.pro
WARNING: Failure to find: qml_audiohw.h
...

Why?! Apparently, a colleague of mine has already reported a bug, and this is the way that it is supposed to be. I’m not sure that I agree. This totally breaks the point of DEPENDPATH to me.

The fix is easy, so now it works, but I’m not happy with loads of ../include in my pro-files due to the way my codebase is structured. I just wonder if this is what we really want…

Update! and it turns out that, yes, that is really what we do want. Apparently this feature has broken code (VPATH causing the wrong files to be picked up). So this is by design.

Update again! running qmake -Wall -r treats the missing header warning as an error. Highly recommended!