[Development] Reviews needed before android integration in two weeks

Thiago Macieira thiago.macieira at intel.com
Wed Feb 6 18:35:23 CET 2013


On quarta-feira, 6 de fevereiro de 2013 11.07.44, Eskil Abrahamsen Blomfeldt 
wrote:
> >> A       lib/rules.xml
> > 
> > I'd rather you found a better place for this file.
> 
> I was planning on putting it into src/android and having it deployed
> into lib/rules.xml when you build for Android.
> 
> Would that be acceptable? I'd like to deploy it in lib/ because then the
> Qt Creator plugin doesn't need to look in two different places for the
> file for Qt 4 and Qt 5 builds.

You install it where it needs to be installed. But the source doesn't need to 
be in lib, especially considering out-of-source builds.

> >> A       mkspecs/features/java.prf
> > 
> > Ossi to judge if the mkpath should be there.
> 
> Ossi wrote the code ;)
> 
> > javac.depends looks like a horrible hack. In fact, while this is a nice
> > feature, the whole file looks like a hack. qmake should be modified to
> > learn how to compile Java instead.
> 
> I disagree. The fewer hardcoded things we have in qmake, the better in
> my opinion. I do agree that the LINK override is hacky, but at least
> it's a working solution with the current system and the cleanest we
> could think of. If qmake is changed later to add a less hacky way to
> override the different compile steps, I'll be glad to adapt to it, but
> for now, I'd like to keep this build system and focus on more pressing
> things before the feature freeze :)

In the long run, I'd like to see if qmake understood how to compile *.java 
when listed in SOURCES.

Then again, if I think a little more about this subject, no, I don't want 
that. Adding features to qmake is a bad idea. We should be looking for a 
better buildsystem instead, so devoting our buildsystem efforts to that 
direction is preferred.

This solution above is just fine.

> > . Also, doesn't qpa/android.prf conflict with android.prf?
> 
> I don't know. I haven't seen any issues. But I don't know if
> qpa/android.prf is actually used for anything.

Then drop it.

> >> M       src/corelib/kernel/qeventdispatcher_unix.cpp
> >> M       src/corelib/kernel/qeventdispatcher_unix_p.h
> > 
> > This one needs a very good explanation.
> 
> Would you mind discussing this with Bogdan on
> 
>      https://codereview.qt-project.org/#change,46798
> 
> Apparently it was needed to fix a deadlock in the event loop on Android.
> It was suggested that we move the hacky implementation into the android
> plugin instead. Would that be an acceptable solution, at least for a
> first go?

It needs a good explanation or it should not be added at all. With all due 
respect to Bogdan, I cannot rule out that he made a mistake in interpreting 
the situation.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130206/71c7eb87/attachment.sig>


More information about the Development mailing list