Merging the android plugin to Qt Creator

[mingw android]

Hi Daniel,

Thanks for all the feedback. I'll send a merge request to the Nokia
4.8 branch containing some of my MinGW build fixes (a workaround for
the command line limit of 8,192 when calling the linker, and defining
UNICODE for building the host tools) and that should suffice for the
QCS.

For reference to some of the changes I've made to Qt, my branch of
4.7.2 that I'm currently using to build Qt Creator (and the installer)
is:

https://gitorious.org/~mingwandroid/qt/mingw-android-official-qt

Also, I'm sure you've probably already seen this, but our master build
script that builds everything (including the kitchen sink) is:

http://quickgit.kde.org/index.php?p=ministro.git&a=blob&h=857f6c4b66f6bb51950d1a5dfcfb85ac45163076&hb=d3cb132e532a52dc7f804782759a0d26df5477d9&f=Necessitas_SDK/build_sdk.sh

Many thanks again for doing this work.

Ray.

On Tue, Jul 26, 2011 at 12:07 PM, Daniel Teske <daniel.teske at nokia.com> wrote:
>> 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?
> Just file a merge request against qt or qt creator. Or point me to a already
> existing MR for either one. For pratical reasons that's how we "define"
> "signing the contributors agreement" at Nokia. :)
>
>> 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...
> Yes we build with msvc. It should be buildable with Mingw though, we do have
> someone actually doing that regularly.
>
>> 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?
> Not quite entirely, but >90% of the code is indeed in a plugin. And the rest
> is really not that much. We've been doing some refactoring in the last couple
> of versions making that possible. We are for the most part done with that.
> There's some ongoing work on the maemo 5/meego/maemo 6/remote linux front, but
> that shouldn't be a big problem for you.
>
>> > 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.
> We use a slightly modified macdeployqt, I have talked with eike and he'll make
> sure that our patches for macdeployqt end up in qt 4.8. He looked at the two
> commits.
> Anyway you can obviously use your current macdeployqt, and we'll handle that
> later. As long as it ain't part of the MR, it's not a blocker.
>
>> > j) bin/necessitas and bin/necessitas.bat
>>
>> These can be deleted, they are not needed.
> Okay fine, can you do that?
>
>> ...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?
> Ah, I just asked our lone mingw user and he confirms the problem and after
> finally taking a few minutes investigating it and consulting documentation, we
> hace changed all "\" to "\\", which is simply more correct. The change is
> already pushed to 2.3. So on your next merge you can remove the change.
>
>> >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.
> I can replace the lower casing by QDir::cleanPath() which does use a uppercase
> C for the drive letter. I'll submit that to master later today.
>
>> 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.
> Creator master requires Qt 4.7.4 (even though that's not released yet)
>
>> 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 ;-)
> Well the plugin will need maintainence. And our android expertise is rather
> limited. :)
>
>> >>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.
> The command line switch is simply for testing, it's not really meant to cover
> the use case the #define covers.
> Like I said, we prefer the settings path to be the same. Or rather we prefer
> one creator binary for all targets. (Also we prefer one sdk for all targets.)
> Though, we do see the point of having it configureable and #defineable.
> And if you really want that, then the patch would need more polish and some
> convincing.
>
>> >>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.
> Hmm, it seems that the code that you disabled is not used by us anymore.
> The relevant person (andre) is currently on vacation, I'll post a patch to our
> internal gerrit removing the code, and let's see what he says once he's back.
>
> daniel
>