Add support for lxlite

[Dmitry A. Kuminov]

For linking Qt and Qt apps, we are stuck to WLINK (ILINK is bogus and cannot handle so many exports as QtGui? has). WLINK is not capable of doing EXE/DLL compression which results into big executables and DLLs even in release builds.

The obvious solution is to use LXLITE to compress the generated EXE and DLL files. LXLITE support must be added to the qmake framework to make its usage fully transparent for the developers.

[Silvan Scherrer]

marking it as minor, as i don't think its really a blocker. even it might be not a big problem to add

[Dmitry A. Kuminov]

I think that I will let configure.cmd find lxlite.exe and on success save the path to it to the 'QMAKE_EXEPACK' qmake variable and add 'exepack' to 'CONFIG'. Otherwise, no variable will be set and no 'exepack' will be added. Note that 'exepack' may be removed from 'CONFIG' on per-application basis to effectively disable the compression of executables and DLLs. The other way around (e.g. override the path and enable) will also be possible.

[Dmitry A. Kuminov]

Done in r313. Please re-run configure.cmd to let the changes take effect.\

Note the following:

• 'exepack' is enabled by default for release builds, but only if lxlite.cmd or lxlite.exe is present in PATH during configure.cmd invocation. You can manually turn it off in .pro (CONFIG -= exepack) if needed. The exepack executable may be overriden using the QMAKE_EXEPACK variable with options in QMAKE_EXEPACK_FLAGS and QMAKE_EXEPACK_POST_FLAGS variables (the latter declares flags placed to the command line after the name of the packed executable or DLL).

• The exepack program is called on the target executable or DLL as part of the link command, after the linker returns success. For this reason, if it fails (for example, the user removes lxlite from PATH), the make process will also fail but a subsequent run will say "nothing to do" (because the target executable will be already generated by the linker and still up to date) and therefore the exepack program won't be executed on that executable. Overcoming this limitation would require a lot of changes in qmake.exe and I really don't think it's worth it -- you can simply delete the target executable (or touch one of the sources it depends on) to cause relinking and another exepack attempt.