Merging the android plugin to Qt Creator

[Daniel Teske]

> > j) bin/necessitas and bin/necessitas.bat
> 
> Ossi reintroduced the LD_LIBRARY_SCRIPT, I still don't really understand
> the topic.
> 
> Ossi? Do you mean Oswald? Is he on holiday at the minute? I've got some MRs
> for Qt 4.8 that Oswald had been looking at that've been inactive for a
> week now, once these are merged, I've got a few more to send... BogDan
> said this was so that the local Qt libs are used instead of any others.
> necessitas.bat can be killed as Windows looks in the same path as the .exe
> for dlls.
Yes, that's him. No, he is in the office, he usually looks at the MRs at least 
once per week, if you want to poke him just come to #qt-labs or #qt-creator.

Yeah, the necessitas.bat is actually already removed. You probably should 
rename the .sh script and edit it to exec bin/necessitas then.
 
> > m) qmakeStep::moreArguments()
> > Adding the "-win32" to the qmake command line. As far as I understand you
> > want to have qmake run in HOST_WIN_MODE on windows. But that is the
> > default if qmake is compiled for windows.
> 
> I'll look into this. I think it's because I compile our qmake for MinGW on
> an MSYS environment so HOST_WIN_MODE is probably not defined.
The qt in qmake's option.cpp looks rather trivial, that seems to imply that 
Q_OS_UNIX is defined for that qmake build?
 
> > p) debugger plugin
> > Always offering all toolchains in DebuggerToolChainComboBox::init
> > The commit message already classifies that as a hack, I just don't
> > understand why it was needed. The check for hostAbi.os() == abi.os()
> > should be true for msys toolchains too. Or is .os() broken for msys
> > toolchains?
> 
> and
> 
> > t) main.cpp myMessageOutput
> > The main motivation for that seems to be:
> > "qInstallMsgHandler so that asserts are not fatal"
> > We like Q_ASSERTS to be fatal, we do have a separate macro QTC_ASSERT for
> > cases where a non fatal handling is possible/desired.
> 
> I was hitting various Q_ASSERTS for things like widgets not being created
> in the main thread and I just wanted them ignored so this was my work
> around. Obviously these asserts are coming from Qt, so QTC_ASSERT can't be
> used for this. Hopefully all these instances are now fixed, but I'll need
> to check that too.
Ah okay.

daniel