Adjust QMAKESPEC_ORIGINAL

[rudi]

When installing the current "Qt Development Libraries and Tools" package, the value of QMAKESPEC_ORIGINAL in %QT_DIR%\mkspecs\default\qmake.conf is hardcoded to "d:\Coding\qt\qt-all-opensource-src-4.6.3-os2\mkspecs\os2-g++\qmake.conf". However, the path should be adapted to caseexactly match the installation path. Otherwise, QtCreator will not work correctly.

[rudi]

There seems to be more about this. Many more files (mostly *.prl) also contain this path. Buried deep in the creator source tree, there is a tools named qpatch. Controlled by a response file it is used to modify both executables and text files. The presence of qpatch.exe as well as the response file in a Windows installation of QtCreator makes me believe, that their install process is modifying files in the Qt source tree when necessary. Starting with ​ftp://ftp.netlabs.org/pub/qtapps/qtc131os2_20110418.exe, the OS/2 installation will attempt to do this as well. For all files listed in "files-to-patch-os2" it replaces the string "d:\Coding\qt\qt-all-opensource-src-4.6.3-os2" and "d:/Coding/qt/qt-all-opensource-src-4.6.3-os2" by the location specified as "Data" path in %ETC%/qtsys.conf.

[rudi]

current qpatch response file

[Dmitry A. Kuminov]

The path in QMAKESPEC_ORIGINAL must be changed by the installer to the actual location of the os2-g++ directory, that's for sure. Or just hardcoded to "..\mkspecs\os2-g++" -- this should work as the only think qmake does with this variable is takes the filename part of its value (e.g. os2-g++ in this case).

What about the rest (e.g. PRL files), QMAKE_PRL_BUILD_DIR is only used on Unix (to make the target depend on some internal libraries and add a rule to build them in place, which is not applicable to OS/2). I will simply disable adding QMAKE_PRL_BUILD_DIR to the .prl file on OS/2, to avoid confusion.

[Dmitry A. Kuminov]

Putting QMAKE_PRL_BUILD_DIR to .prl is removed in r898.

[Dmitry A. Kuminov]

In ​68e782, I added support for relative QMAKESPEC_ORIGINAL paths.

In r899 I changed configure.cmd to put the relative paths in there.

Note that while playing with various QMAKESPEC_ORIGINAL values before the fix, I couldn't screw Qt Creator up in a visible way, no matter what I put there (which results in QMAKESPEC being seen as "default" in Qt Creator). I didn't analyze all the code using the mkspec() and mspecPath() values but I got the impression that it may cause the blocks of code that depend on the platform-compiler pair to go the wrong way. So I fixed it in Qt Creator to be on the safe side.

Rudi, replace QMAKESPEC_ORIGINAL=<path_to_mkspec>
mkspecs
os2-g++ with QMAKESPEC_ORIGINAL=..
os2-g++ and try my Qt Creator branch on your side to see if it works now as expected for you. Feel free to reopen this defect if not.

JFYI. In qmake, if QMAKESPEC_ORIGINAL is set wrongly, the only thing I found broken is that conditions like os2-g++ {...} don't work any more. (the os2 {...} ones still work because the platform qmake is targeted at is detected using other means, at least for the purposes of conditional blocks).

[rudi]

Just a note: On my Windows system, mkspecs/default/qmake.conf looks like this:

QMAKESPEC_ORIGINAL=C:/Qt/4.7.3-mingw/mkspecs/win32-g++

include(../win32-g++/qmake.conf)

I'm wondering if we could do that as well instead of basically duplicating mkspecs/os2-g++/qmake.conf...

[Dmitry A. Kuminov]

I actually did something even more cool. Thanks to QMAKESPECDIR that we add to Makefiles on OS/2 since long, we don't even need to have any other support file in mkspecs/default (e.g. *.h or *.cmd files) except qmake.conf that may be simplified to just contain one include statement and the QMAKESPEC_ORIGINAL definition (i.e. as on Windows). This reduces the unnecessary and annoying data duplication.

This is done in r974 and r975, the updated configure.cmd will take care of it.