Windows qmake issue.

mingw.android mingw.android at gmail.com
Mon Jul 11 21:00:16 CEST 2011


Hello,

I've been sorting out the Windows version so that cmd.exe programs 
(copy, del) are used instead of posix (cp, rm) ones, in general, the way 
this is achieved is, in qmake.conf:
...
include(../common/linux.conf)
...
contains(QMAKE_HOST.os,Windows) {
     # Not having sh.exe in your path causes this condition to pass
     # To build Android Qt on Windows, this block must not be evaluated.
     isEmpty(QMAKE_SH) {
         QMAKE_COPY           = copy /y
         etc...

QMAKE_HOST.os always works, however, QMAKE_SH is set depending on 
whether sh.exe is found in the PATH. This is an ok restriction (there's 
no reason to have MinGW's sh.exe in your path on Windows), though 
perhaps I should warn the user if this is detected... However, there's 
another fly in the ointment:

android-qt-creator/src/plugins/qt4projectmanager/qtversionmanager.cpp, 
line 184:
QFileInfo fi(mingwDir + QLatin1String("/bin/g++.exe"));
I think mingwDir comes from the registry, and this finds g++.exe, which 
then gets added as a toolchain, which causes e.g. C:\usr\bin to get 
added to the PATH. With this added, sh.exe gets found, QMAKE_SH set and 
things fall over.

I tested this theory by renaming g++.exe so it didn't get found and with 
this change made, the msdos commands get used correctly.

I guess this is a general QtCreator issue, but can anyone think of a 
clean solution for this? Failing that, I'll disable this code that looks 
for g++.exe for the next build and add something to the release notes 
saying that NQTC can't be used to develop MinGW apps and this is 
something I don't really want to do.

Cheers,

Ray.



More information about the Necessitas-devel mailing list