<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Hi, <br></span></div><div><br><span></span></div><div><span>Welcome back !</span></div><div><span></span></div><div>Please accept my apologize for the slow replay.</div><div><br></div><div>I tried to apply your patches 2.3-stagin but it doesn't compile anymore, should I create another branch and merge master branch of upstream qt-creator ? This mean to create another merge request !<br></div><div><br></div><div><br></div><div>Cheers,</div><div>BogDan.<br></div><div><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><font face="Arial" size="2"><hr size="1"><b><span
style="font-weight:bold;">From:</span></b> Daniel Teske <daniel.teske@nokia.com><br><b><span style="font-weight: bold;">To:</span></b> necessitas-devel@kde.org<br><b><span style="font-weight: bold;">Sent:</span></b> Wednesday, August 31, 2011 5:25 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: Merging the android plugin to Qt Creator<br></font><br>Hi,<br><br>I'm back from vacation and had another look at the diff between master and 2.3-<br>staging.[1] For that I merged master into 2.3-staging, since a few changes <br>that I did in master aren't yet in the 2.3-staging branch.<br><br>There are currently 5 merge conflicts, none particular complicated to figure <br>out. Unfourtanetly that didn't compile, due to a header cleanup patch by <br>Friedemann. For reference, the 0001-Compile-fixes is what was required to make <br>it compile again. <br>Also the exporting FolderNavigationWidget is no longer needed, since the
<br>showInGraphicalShell method is moved in master, see 0001-Compile-fixes<br><br>Also I have prepared two patches for the android branch:<br>- 0002-Remove-no-longer-used-ressource.h <br>The file is a left-over from the fix Ray did to the qtcreator.rc file. Since it's <br>now fixed in a different way, the file is no longer needed.<br><br>- 0003-Code-stylistics-to-RemoteGdbServerAdapter-changes.patch<br>I have adjusted the code a little bit to fit the creator code sytle a little <br>better. That is using !isEmpty() instead of size() and adding spaces around <br>operators. Andre thinks the patch is now fine.<br><br>Also<br>> n) lowerCasing of paths in qt4buildconfiguration.cpp<br>That turns out to be somewhat more involved, I still have it on my todo list.<br><br>> j) bin/necessitas and bin/necessitas.bat<br>Ossi reintroduced the LD_LIBRARY_SCRIPT, I still don't really understand the <br>topic.<br><br>> s) main.cpp #ifdef<br>> There is a
change in main.cpp changing the plugin search paths to be only<br>> searched on the "matching" platform.<br>I cherry-picked that change to master.<br><br>> p) debugger plugin<br>> Disabling setting PYTHONPATH. Why is that needed? Note that the code that<br>> is disabled was rewritten a lot since you disabled it.<br>We removed the same code that was #ifdefed out in master now, so on merging, <br>just remove the code. <br><br>So going over my intial todo list, I still have a few open questions. As far <br>as I can tell they are all for Ray. :)<br><br>> m) qmakeStep::moreArguments()<br>> Adding the "-win32" to the qmake command line. As far as I understand you<br>> want to have qmake run in HOST_WIN_MODE on windows. But that is the<br>> default if qmake is compiled for windows.<br> <br>> p) debugger plugin<br>> Always offering all toolchains in DebuggerToolChainComboBox::init<br>> The commit message already classifies that
as a hack, I just don't<br>> understand why it was needed. The check for hostAbi.os() == abi.os()<br>> should be true for msys toolchains too. Or is .os() broken for msys<br>> toolchains?<br><br>and<br>> t) main.cpp myMessageOutput<br>> The main motivation for that seems to be:<br>> "qInstallMsgHandler so that asserts are not fatal"<br>> We like Q_ASSERTS to be fatal, we do have a separate macro QTC_ASSERT for<br>> cases where a non fatal handling is possible/desired.<br><br>Ray, any comments on them would be nice.<br><br> <br>daniel<br><br>[1] That seemed to be the most recent branch<br><br>_______________________________________________<br>Necessitas-devel mailing list<br><a ymailto="mailto:Necessitas-devel@kde.org" href="mailto:Necessitas-devel@kde.org">Necessitas-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/necessitas-devel"
target="_blank">https://mail.kde.org/mailman/listinfo/necessitas-devel</a><br><br><br></div></div></blockquote></div></div></body></html>