qmain.prl contains incorrect paths

In our company, we have a continuous integration system similar to Jenkins.

We usually check in our source code as well as build tools into our source code repository (perforce), for example, compilers and Qt, and configure our continuous integration system to pull both the tools and the source code from the repository and build our program.

I'm in charge of updating the Qt in the repository. I usually download the Qt installer from the official site and install it on my local hard drive. I then upload my local install to the repository.

Of course, I also change the qt.conf and qmake.conf when uploading to the repository if needed, because on our build machines, the Qt path could be different from my local install location.
I have been doing this since Qt 4.7, things worked fine till even Qt5.3.0_Beta. However, recently, I tried to upgrade to Qt 5.3.1 and I met a linking problem of missing QtCore.lib file.
Qt somehow still remembers my local install location and tries to find QtCore.lib from there. But that location doesn’t exist on our build system.
If you open the Makefile.debug file qmake generates, you will find the following:
LIBS = glu32.lib opengl32.lib gdi32.lib user32.lib /LIBPATH:C:\msvc2010_opengl\lib C:\msvc2010_opengl\lib\qtmaind.lib /LIBPATH:C:\Qt\Qt5.3.1\5.3\msvc2010_opengl\lib C:\Qt\Qt5.3.1\5.3\msvc2010_opengl\lib\Qt5Cored.lib /LIBPATH:\lib C:\msvc2010_opengl\lib\Qt5Widgetsd.lib C:\msvc2010_opengl\lib\Qt5Guid.lib C:\msvc2010_opengl\lib\Qt5Cored.lib

C:\msvc2010_opengl\lib is the correct location for lib files on the build system, whereas C:\Qt\Qt5.3.1\5.3\msvc2010_opengl\lib is the Qt install location on my local machine. I didn’t know how qmake could still remember it and why it generates inconsistent paths. (for qtwidgets, it looks into the right path, but the qtcore path is always wrong.)

I have tried many ways to fix this, including defining Qt_INSTALL_LIBS and QT_HOST_LIBS in the qt.conf file. I also tried specifying
QT_MODULE_LIB_BASE,
QMAKE_LIBDIR
None of them worked.
Finally, I had no choice but debugging qmake myself. (BTW, function QMakeParser::read is horribly ugly.)

It turned out that the wrong paths come from these two files:
lib/qtmain.prl
lib/qtmaind.prl

inside them, there are hardcoded Qt lib paths:
QMAKE_PRL_LIBS = /LIBPATH:C:\\Qt\\Qt5.3.1\\5.3\\msvc2010_opengl
lib C:\\Qt\\Qt5.3.1\\5.3\\msvc2010_opengl\\lib
Qt5Core.lib

Qmake directly reads these two files and adds those two paths to the makefile. I think this is a bug.
For now, I modified these two files to use:
QMAKE_PRL_LIBS = /LIBPATH:$(QT_INSTALL_LIBS) $(QT_INSTALL_LIBS)
Qt5Core.lib
Which solved my problem.

In my opinion, as long as PREFIX and QT_INSTALL_LIBS are correct, qmake should be able to generate correct makefiles. Event it needs to read these two files, the two files shouldn’t contain hardcoded absolute paths.

Strange though, I checked the qtmain.prl file in Qt5.3.0_beta, it contains the hardcoded path too! But I didn’t seem to have any issues before. Maybe this is due to some recent change to qmake.exe, which didn’t load qtmain.prl before.

This bug can be easily reproduced. Just use the official installer to install Qt on a windows system. By default, the path is C:\Qt\5.3.1\5.3\msvc2010_opengl.
Then, rename the Qt path to something like: C:\Qt\test\5.3\msvc2010_opengl, and try to generate makefiles with qmake.
Open the makefile.debug file, you will still see C:\Qt\5.3.1\5.3\msvc2010_opengl.