Fix support for 'console' and 'windows' CONFIG flags

[Dmitry A. Kuminov]

The 'console' flag should generate a console application (that requires standard input/output streams and a text mode window attached to it).

The 'windows' flag should generate a PM application that doesn't have standard input/output or a text mode window attached.

Currently, qmake passes special flags to WLINK depending on whether 'console' ("SYSTEM os2v2") or 'windows' ("SYSTEM os2v2_pm") is in CONFIG but these flags are not understood by a standalone patched WLINK version we use because system configuration files are missing.

[Dmitry A. Kuminov]

The only possible way to fix this w/o changing WLINK, GCC (emxomfld) or any other 3rd party tool is to generate a temporary hidden .DEF file for every .EXE and specify the application type ('WINDOWCOMPAT' or 'PM') in this .DEF file.

[Dmitry A. Kuminov]

BTW, for those who get

Error! E3057: system block os2v2: executable format has been established

when linking Qt or Qt apps, a workaround is to remove -Zlinker "SYSTEM os2v2" and -Zlinker "SYSTEM os2v2_pm" from mkspecs/default (and from mkspecs/os2-g++) -- these directives don't do anything useful anyway.

The reason for the error seems that you have watcom configuration files defining these "os2v2" and "os2v2_pm" systems but emxomfld (that actually executes WLINK) has already specified the application type in its command line arguments (or in the .DEF file, I don't recall exactly) and therefore WLINK complains about the redefine attempt.

[Dmitry A. Kuminov]

Done in r293 (and r292). As planned, using an implicit .DEF file. Silvan, please check if it works for you (don't forget to run configure.cmd).

[Silvan Scherrer]

either i did something wrong or it does not work anymore.
i updated with lafest svn and run configure.cmd. after that i run make. but make gives me an error.
cd src\tools\moc && make.exe -f Makefile
make.exe [1]: Entering directory e:/trees/qt4/src/moc
make.exe -f Makefile.Release
make.exe [2]: Entering directory e:/trees/qt4/src/moc
SYS0003: The system cannot find the path specified
make.exe [2]: * [release\moc.apptype.def] Error 1

[Dmitry A. Kuminov]

Got it here. moc uses some weird non-standard output path overriding, I can't find where it does yet.

[Dmitry A. Kuminov]

Okay, it was a bunch of problems. Solving any single one would solve the original issue but I decided to fix them all to make sure nothing similar happens in the feature.

1. shared/static output directory fixups were applied after processing all .pro/.pri files, right before generating the makefiles in qmake. As a result, we had no chance to get the correct OBJECTS_DIR value (as it later appears in the generated Makefile) in our default_post.prf file and used a wrong one for DEF_FILE -- hence the message about the wrong path. Fixed in r294 (forgot to mention that it's a vendor bug).

2. The path to the implicit .DEF file was comprised of qmake variables (which were wrong in case of moc due to above). In r295, I changed it to use make variables instead which always have the final values.

3. And finally, moc for some reason overwrites the usual OBJECTS_DIR value (which tmp/obj/blabla for the whole Qt source tree) to the current directory (.) in its .pro file. I don't see any rationale in that; and it perfectly builds with the default value. So I removed OBJECTS_DIR override in r296. Probably it's a leftover from the times when it was necessary (may be considered as a vendor bug too unless I overlooked something and it is still needed on some platforms).

[Dmitry A. Kuminov]

Fixed a small r294 regression in r297.

[Dmitry A. Kuminov]

In r298, if no 'windows', no 'console' is found in CONFIG, I set the default application type to 'windows' if it's a release build against QtGui and 'console' in all other cases. This is partly compatible with the Windows platform (where it is always 'windows' by default) but looks more sane to me.

I think this defect is therefore fixed.