Merging the android plugin to Qt Creator

[mingw android]

Urgh, I've been too busy at work..

Thanks very much for looking into this Daniel.

mingw.android == Ray Donnelly.

I'm pretty sure I already did sign the Contributors Agreement, but
I'll happily sign it again. Where would I go to do that?

The issues that BogDan didn't discuss I'll address at the top:

So you guys build the official, released Qt Creator with MSVC then?
For me, it's all via GCC, and that's where some of the problems came
in...

You mention the "android plugin" and I know BogDan recently split the
source off, but is it still really the Qt4ProjectManager plugin that
this code gets built into? Or has it been made possible to split it
off as an entirely separate plugin?

> g) macdeployqt/*
What do you guys do for relocating plugins and Qt libs then? I had to
put a few hacks in as it didn't work on case sensitive filesystems
(plugins vs PlugIns), and also some objects weren't getting considered
for relocation, so I hacked that in a bit.

> j) bin/necessitas and bin/necessitas.bat
These can be deleted, they are not needed.

>k) Settings Path and Renaming to Necessitas
>...
> If you do want to have a different name/settings path, then there are quite a few places which need to be fixed and the default should be "Qt Creator" not "Necessitas Qt Creator"
I guess it's irrelevant when we joint Qt Creator mainline, but I'm not
sure I get you, do you mean use a different organization name but the
same application name?

...windres.exe in MinGW can't handle .rc files that look like:
IDI_ICON2               ICON    DISCARDABLE     "winicons\c.ico"
instead, it needs:
IDI_ICON2               ICON                    "winicons\\c.ico"
which happens to be what Visual Studio uses (if you load the original
.rc into VS and re-save it, it'll convert all \ to \\, in fact this is
exactly what I did). Another fix for this would be to alter
windres.exe to not treat \ as an escape character (which is what I'd
guess is the root of the problem) but I figured that my fix was the
more compatiable option anyway?

>n) lowerCasing in qt4buildconfiguration.cpp
>#ifdefing out the lowercasing of specs
>"Don't do the toLower stuff on lots of paths when Q_OS_WIN and __MINGW32__ is defined. This is an aesthetic thing. I don't like showing all pahs in lower case."
>The paths are lowercased to compare them against each other, without the owercasing the comparision will fail for paths that are the same. Thus since the change is just for aesthetics, I'd back it out again."
Can you not do the lowercasing at the point of comparision instead?
That way both requirements are met. In my Qt 4.7.2 (see below) I went
though all the code to make sure that e.g. C: is used consistently
instead of mixing C: and c:, and with this done, the toLower stuff was
not needed anymore.

Another issue is that, currently, the Windows build uses my own
version of Qt 4.7.2 which I've made changes to to support MSYS build.
There's nothing too drastic in there, and BogDan has said that he
wants to build Qt Creator and the installer framework with our version
of lighthouse anyway and many of my Qt 4.7.2 MSYS changes (the
host/build side fixes) are in lighthouse.

BogDan, what will happen to Necessitas if it's all main-lined? I guess
there's still plenty to do, but that's mostly on the side of things
that you hack on, I wonder whether I'll just do NDK stuff after that?
Or maybe I'll actually use it instead of just building releases of it
all the time ;-)

Slightly untidyly, there are more comments in-line!

On Fri, Jul 22, 2011 at 8:02 PM, BogDan <bog_dan_ro at yahoo.com> wrote:
> Hi,
>
>
> I've created another branch "mr-stagging" for this job.
>
> [..]
>>b) License
>>Some files currently have no license header at all
>
> Now  all .cpp and .h files from android plugin folder should have license header completed.
>
> [..]
>>0001-Remove-wrong-merge-resolution.patch
>>0002-Remove-accidentally-added-.commit.template.patch
>>0003-Remove-unecessary-whitespace-changes.patch
>>0004-Unecessary-change-to-import-code.patch
>>0006-Reformat-deployment.pri-to-be-more-readeable.patch
>
>>0007-Bump-stub-version-of-template.patch
>>0008-Remove-settign-of-ANDROID_NDK_HOST-from-necessitas.b.patch
> Pushed.
>
>>0005-Simplfy-template-code.patch
> Not pushed, without setBaseUrl thing, qml engine will add file:// in front of
> the file and it will not work with current android assets implementation
> which need a file patch to start with a "/" or directly with its name.
>
>
> [..]
>
>>
>>f) mingw/*
>>Those files need to be removed from the MR for hopefully obvious reasons.
>>
>>g) macdeployqt/*
>>============= TODO look at the patches
>>There is unfourtanetly no maintainer for macdeployqt, but the patches should
>>be made against the macdeployqt in qt.
>>
>
>
> I've remove them from QtCreator's "mr-stagging" branch, Ray please move this file to ministro repo.
>
>>h) Changes in src/tools/qpatch
>>After a quick discussion at the office we removed src/tools/qpatch completely
>>from master since it is neither used by the stand alone creator packages nor
>>by the sdk and is known to be buggy.
>>I'd recommend instead of patching and using qpatch to use the facilities in
>>the QtSDK found in installer-framework/installerbuilder/libinstaller/qtpatch
>>and installerbuilder/libinstaller/qtpatchoperation.cpp and then backing out
>>the changes to qpatch
>>
>
> Because we still need it, I'll move it to ministro repo.
>
>
>>i) build.sh
>>We don't want that as part of the creator repository. As far as we are
>>concerned building creator should be done in a normal cmd shell on windows and
>>not in a msys shell.
>
> Removed.

It isn't used anymore. We use common build scripts in ministro. I
still want to be able to build Qt Creator from MSYS as our build
script is a shell script and builds not only Qt C, but all the rest of
the Necessitas SDK (host Qt, android Qt, QtC, installer, Python, gdb,
repackaging Google packages) unattended.

>
>>
>>j) bin/necessitas and bin/necessitas.bat
>>The setting of ANDROID_NDK_HOST seemed to be a left over from before setting
>>it in androidtoolchain.cpp, so I removed it, see attached patch.
>>We used to have a similar LD_LIBRARY_PATH setting script on linux but after
>>some internal discussions we removed it. On windows
>>
>
> Can you share with use your secret ?
>
>>k) Settings Path and Renaming to Necessitas
>>We think if we merge the android plugin into creator, then there is no point
>>in renaming Qt Creator and no point in using a different settings path. The sdk
>>team also wants to produce "one" sdk that can install components from different
>>providers.
>
> Great, agreed !
>
>>If you do want to have a different name/settings path, then there are quite a
>>few places which need to be fixed and the default should be "Qt Creator" not
>>"Necessitas Qt Creator"

I still quite like the idea of using a #define (somewhere better than
from the command line) for the vendor and application name, as it made
it easy for us to separate the settings off for each version (I have
both Qt Creator and Necessitas installed), and I guess it would make
it easy for anyone else who wants to branch off Qt Creator for another
new platform, but I really don't mind if the define is removed. I
passed it in as CFLAGS which makes the compile commands a bit untidy.

>>
>
> We'll keep them in our "private" branch to shipour own SDK installer. I choose
> to make those changes because I didn't want to pollute official QtCreaor settings :)
>
> [..]
>>
>
>>p) debugger plugin
>>The debbuger plugin has quite a few changes, some of them seem to be hacks.
>>Also I'm not that well versed in the debugger plugins code, though I discussed
>>a earlier diff with the debugger maintainer (Andre).
>>I'm somewhat confussed whether you are using the python dumpers, or not.
>
> We are using python dumpers !
>
>
>>So, the changes:
>>Adding "arm-linux-androideabi" to gnuTargets: fine
>>
>>soLibSearchPath: in general looks fine, andre mentioned some details he wanted
>>to see fixed
>>
>
> Which one ?
>
>>
>>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?
>>
>
> Ray, any comments ?

I'll look into this again and get back to you. I think hostAbi.os() is
probably broken.

>
>>
>>Disabling setting PYTHONPATH. Why is that needed? Note that the code that is
>>disabled was rewritten a lot since you disabled it.
>>
>
> We choose to "hardcode" PYTHONPATH into gdb, so gdb doesn't need any PYTHONPATH evn variable set.

The pythonpath isn't even hardcoded (by pythonpath I mean the internal
variable that sometimes adopts PYTHONPATH), it just determined as a
path relative to argv[0]. It used to be that having PYTHONPATH in your
env. could cause problems. What do you normally do for Python on
Windows? There's probably no reason that we can't use your version on
Windows instead.

>
>>
>>q) abi.h abi.cpp
>>The change looks good, but can't be merged without the rest of the android
>>plugin.
>>
>>r) templates/qtquickapp/*
>>The changes looked almost okay. I didn't understand the setBaseUrl() change,
>>nor can I see how that makes sense. I reformatted some of the code for better
>>readability and added a bumping of the template version. (Projects with prior
>>template versions are automatically updated then.) See the attached patches.
>
> Using setBaseUrl qml will not add "file://" in front of your url.
>
> [..]
>>
>>u) Settings SystemScope to UserScope
>>Quite a few settings (if not all) are using the UserScope instead of the
>>SystemScope. Why is that needed?
>>
>
> Because SystemScope is not user writable (if you'll install the SDK using "sudo" that file can't be written by a normal user), so we choose to move everything to user's home, if is not correct we'll revert that change.
>
>>I might have missed a few changes here and there.
>>
>>I'm looking forward to working on that. :)
>>
>>daniel
>>
>
>
> Thank you for your time !
>
> Cheers,
> BogDan.
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel
>