Hi Thiago, I disagree to some extent, see below.
On 9/1/11 1:43 PM, "ext Thiago Macieira" <[email protected]> wrote: >On Thursday, 1 de September de 2011 13:10:30 Thiago Macieira wrote: >> If I correct src.pro line 11 to the proper conditional (instead of the >> double negative), configure finishes without error. I'll let you know >>if >> this compiles. > >Ok, it compiled with -no-gui -no-v8 on IA-64 and it compiled with -no-v8 >on >MIPS. > >So the -no-v8 option seems to work for QtBase. > >My suggested course of action is therefore: > >1) immediately fix src.pro line 11 Yes, that's a plain old bug... >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. >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. > >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. 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. > > >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. > > - Qt as a whole must work as expected on all supported platforms. The >term > "as expected" is loosely defined to mean "what one expects to do on >those > platforms". > > - 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. > >If QtDeclarative or QtWebKit want to mandate the use of V8, they can, >provided >they announce and discuss as I noted above. Neither module needs to be >supported on all platforms -- only where they are relevant. > >In QtDeclarative's particular case, this exception expires when QtWidget >moves >from Done to Deprecated. QtWebKit would be in the same situation if HTML5 >were >to become the de-facto way of doing desktop UIs. > > >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 feature set up and running. But it will most likely not be the most performant thing on earth. But I think we should wait and look at some benchmarks of it first (I'm trying to get some numbers). Cheers, Lars _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
