Merging the android plugin to Qt Creator

mingw android mingw.android at gmail.com
Wed Aug 31 14:40:02 UTC 2011


Hi Daniel,

Welcome back, responding inline again.

On Wed, Aug 31, 2011 at 3:25 PM, Daniel Teske <daniel.teske at nokia.com>wrote:

> Hi,
>
> I'm back from vacation and had another look at the diff between master and
> 2.3-
> staging.[1] For that I merged master into 2.3-staging, since a few changes
> that I did in master aren't yet in the 2.3-staging branch.
>
> There are currently 5 merge conflicts, none particular complicated to
> figure
> out. Unfourtanetly that didn't compile, due to a header cleanup patch by
> Friedemann. For reference, the 0001-Compile-fixes is what was required to
> make
> it compile again.
> Also the exporting FolderNavigationWidget is no longer needed, since the
> showInGraphicalShell method is moved in master, see 0001-Compile-fixes
>
> Also I have prepared two patches for the android branch:
> - 0002-Remove-no-longer-used-ressource.h
> The file is a left-over from the fix Ray did to the qtcreator.rc file.
> Since it's
> now fixed in a different way, the file is no longer needed.
>
> Great.


> - 0003-Code-stylistics-to-RemoteGdbServerAdapter-changes.patch
> I have adjusted the code a little bit to fit the creator code sytle a
> little
> better. That is using !isEmpty() instead of size() and adding spaces around
> operators. Andre thinks the patch is now fine.
>
> Ditto.


> Also
> > n) lowerCasing of paths in qt4buildconfiguration.cpp
> That turns out to be somewhat more involved, I still have it on my todo
> list.
>
> Ok.


> > 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.


> > s) main.cpp #ifdef
> > There is a change in main.cpp changing the plugin search paths to be only
> > searched on the "matching" platform.
> I cherry-picked that change to master.
>
> > p) debugger plugin
> > Disabling setting PYTHONPATH. Why is that needed? Note that the code that
> > is disabled was rewritten a lot since you disabled it.
> We removed the same code that was #ifdefed out in master now, so on
> merging,
> just remove the code.
>
> So going over my intial todo list, I still have a few open questions. As
> far
> as I can tell they are all for Ray. :)
>
> > 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.

>
> > 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.

>
> Ray, any comments on them would be nice.
>
> I'm currently very busy at work but I'll try to make it a priority to
investigate these remaining few issues.

Cheers,

Ray.

>
> daniel
>
> [1] That seemed to be the most recent branch
>
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20110831/ac0f72d1/attachment-0001.html>


More information about the Necessitas-devel mailing list