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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development