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