On 9/1/11 2:58 PM, "ext Thiago Macieira" <[email protected]> wrote:
>On Thursday, 1 de September de 2011 14:09:53 [email protected] wrote: >> >2) add a configure-time check for enabling or disabling V8. >> >3) withhold any and all mandatory uses of V8 inside Qt Base. The module >> >must >> > >> > compile with the same API until further decision. >> >> We'll work on getting the ARM simulator that built into V8 working on >>all >> platforms. That should resolve the feature parity problem, but >>performance >> might not be the best everywhere. > >That's fine. > >I'm looking at it right now and the first problem I see is how to get it >running on 64-bit platforms. My idea is to keep a 32-bit "high word" in >the >simulator that shadows all registers. The simulator runs with 32-bit >registers, but whenever it needs to call into host code, it needs to >obtain >the high part of the 64-bit register. > >> >4) restore QtWebKit functionality on MIPS by featture-freeze (MIPS is >> >heavily >> > used in the set-top-box market, where Qt and QtWebKit are quite >> >important) >> >> If there is someone that is willing to do the work, I'm all for it. But >>it >> doesn't happen by itself. > >If the ARM simulator works, that's a start. Full MIPS functionality would >be >preferred, considering how important Qt is on MIPS. I agree. There's work ongoing to fully support V8 on MIPS. I'm not 100% sure what the status is right now, but I heard it's working. That would be the best solution to support MIPS. > >I suggest talking to the people who helped Netflix and the like and see >if they >can help. > >In any case, the provision of "don't drop until people have had time to >react" >still applies. > >> >In order to determine if V8 can be made a mandatory component of Qt, we >> >need >> > >> >to discuss the fate of the following platforms: >> > MIPS 32-bit big-endian >> > MIPS64 (both endians) >> > Sparc 32- and 64-bit (big endian) >> > PowerPC / POWER6 32- and 64-bit (big endian) >> > IA-64 (both endians) >> > SH4 and others >> >> 95% of Qt users are using it on x86/x64 or ARM. I am not very tempted by >> the idea of holding these 95% back to fully support processors that .1% >>of >> our users use. >> >> With open governance, it can't be the project's goal to stay on a least >> common denominator. We need to move ahead and create the best possible >> platform if we want to stay relevant. >> >> It's up to the people that have an interest in SH4 or IA-64 to help >> provide full support for that platform. If nobody steps up, it will at >> some point not be supported anymore. > >Agreed. But these people need time to do it. > >> Let's also not forget that Qt 4.8 is out there and working nicely. If >>some >> of the above platforms follow a bit later with working fully on Qt 5 >>it's >> not the end of the world. > >No, but there's the danger of the temporary becoming the permanent. > >> >The following are the guidelines I suggest: >> > - Qt Base must always compile on those platforms, with no API missing >> > (that means, we can't use V8's regular expression engine until the >> >matter >> > is settled) >> >> We can and should use it IMO. The reason is that this is a switch that >> would also change the default syntax from Qt own syntax to a JS >>compliant >> syntax. I don't want to do this in a minor release. > >Agreed, which is why V8 regexp must work everywhere. Whatever may come >out of >QtGui, QtWidgets, QtWebKit, QtDeclarative, at least QtCore needs to be >everywhere. > >> > - Modules other than Qt Base may elect not to support some platforms >> >where >> > they are not very relevant. Dropping of *current* support must be >> >announced >> > and discussed, with the community given ample time to react, >>including >> >time >> > to develop code before the feature freeze (meaning: *after* the new >> > repository is live). The correct thing to do would be to give time >> >before >> > the merging, but we've jumped the gun there. >> >> I remember that you were part of many of the discussions. The move to V8 >> was also something I said in May already when announcing Qt 5. So one >> can't really say that it wasn't announced. > >V8 was announced. V8 blocking the build of Qt Base and/or QtCore wasn't. > >And we still don't have the repository and mailing lists. If I want to do >the >work, I need to be able to discuss things and time get my patches in. >Before >feature freeze. Yes, I'm painfully aware of the missing repository :( Let's see how we manage this, but I am right now assuming that fixes for platforms can go in for another while even after feature freeze. > >> >Note I managed to compile the ARM simulator on the MIPS target after >> >modifying >> >the source code, but I have no way of testing if it works. I will try >>to >> >do >> >the same for IA-64 ILP32 little-endian and see if the test runs. If the >> >simulator works, 32-bit little-endian platforms are probably safe. That >> >leaves >> >the 64-bit as well as 32-bit big-endian platforms to be tested. >> >> The simulator should work on all platforms, and it's a way to get the >>full > >It doesn't and that's the problem. The ARM simulator is supported right >now on >i386 only. Not even x86-64 is supported. See above. Hmmm... I didn't know that. I thought it was generic C++ code interpreting ARM instructions. Kent, can you have a look? Lars _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
