A multi-arch rpm will continue to grow in size for each supported platform. Youy'll get the overhead of download this whoile thing to upgrade your device. Also you'll need to upgrade if some other arch changes in which you have no interest.
If there are arch-dependent bin components (as apposed to the intermediate language approach), then it would make more sense to have the noarch qml part require a capability provided by a bunch of arch rpms. [Sent from my phone] ----- Original Message ----- From: Sander van Grieken [mailto:[email protected]] Sent: Tuesday, May 31, 2011 02:41 AM Cc: meego-dev <[email protected]> Subject: Re: [MeeGo-dev] MeeGo app model in 2012: Rethinking the MeeGo app model to be more platform agnostic What about a multi-arch RPM approach, where binaries for multiple architectures are contained in a single RPM, but where only the arch specific variant is installed? This would avoid the size increase of a multi-arch ELF approach, and avoid the (possible) performance loss and (possible) execution problems of a (not yet mature) intermediate format. -Sander On Dinsdag 31 Mei 2011 11:25 CEST, Carsten Munk <[email protected]> wrote: > Yes, indeed - I've been fed the usual JVM and JIT knowledge through my > university education like many others, but this isn't the approach > taken in MeeGo currently as we have to write C++ for our native Qt > Quick extensions and we don't have a JVM on each device. > > I feel that LLVM could give some good opportunities for MeeGo in this area. > > BR > Carsten Munk > > 2011/5/31 Zhang, Zheng <[email protected]>: > > Android has done most of such jobs via JVM. > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Carsten Munk > > Sent: Tuesday, May 31, 2011 2:11 PM > > To: meego-dev > > Subject: [MeeGo-dev] MeeGo app model in 2012: Rethinking the MeeGo app > > model to be more platform agnostic > > > > Hi, > > > > One of the disadvantages of MeeGo is that unlike Android and other OS'es, > > we don't provide a way for developers to provide one MeeGo compliant RPM > > for typical MeeGo applications+extensions that will run on all MeeGo > > devices, no matter if it is IA, ARM, MIPS. I'd like to spark a technical (+ > > compliance) discussion on if we can somehow make this reality. > > > > I'd like a world where it matters less what architecture a MeeGo device > > runs, or even specific optimization flags/architectures not in line with > > what meego.com builds when it comes to compliance, allowing more > > flexibility in hardware choice and hardware directions over the long term. > > > > Opinions that this isn't feasible is more than welcome :) Since we're all > > about fast innovation now, here's one idea to think about. > > > > With the news of Qt5 the new future application model[1] is clear. It > > motivates that 'While offering all of the power of native Qt using > > C++, the focus should shift to a model, where C++ is mainly used to > > implement modular backend functionality for Qt Quick.'. This will cause a > > development model for MeeGo API apps along lines of: > > > > * QML applications, platform agnostic, distributed as 'noarch' RPM > > packages. Contains QML/js files, resources, etc. > > * Qt Quick modules, platform agnostic, written in QML/js, distributed as > > 'noarch' RPM packages (think widget sets, etc) > > * C++ Qt Quick modules, platform specific, distributed as > > i586/armv7hl/mips/etc RPM packages. Contains compiled native code specific > > to a target processor. Typically shared objects. > > > > As you can see, we're 2/3 there to where it essentially doesn't matter what > > the underlying device runs, except that it provides certain APIs/runtimes > > for the QML apps to use. Having a MeeGo Core that we can optimize towards > > specific use cases and hence a wider market for MeeGo to be used in. > > > > I'd like to propose that we go to a model where we have one MeeGo API SDK > > with one toolchain that targets the MeeGo platform, no matter the hardware > > architecture. This means, take C++ Qt Quick modules and build them into a > > platform agnostic format (intermediate language) that is then translated by > > an application store or by device itself into native code, which is then > > run on the device. > > > > Google has already been working on a similar approach for their Native > > Client work, based on the LLVM intermediate format[2] and I think this is > > plausible to do for MeeGo too in a similar fashion in a short timeframe. > > They have been working on shared objects as well[3]. > > > > Now, there are some issues to be discussed and I'll list some of them: > > > > 1) Performance loss - will there be any noticable loss in application > > performance? Will it be mitigated by the fact the MeeGo platform + Qt stack > > is optimized to the target as that's where the real work goes on usually? > > 2) Will ARM or IA/Atom specific optimizations be lost if LLVM is used? > > 3) Licensing issues (GPLv3/LLVM license/etc?) > > 4) Security implications/signing issues/etc > > 5) Obfuscation and reverse engineering implications of IL being used. > > 6) Compliance implications > > 7) Hardware specific extensions > > > > And last of all: > > > > Is it plausible to have a C++ extension in LLVM intermediate language > > (targetted towards a fictional machine description) that links without > > issue into the native Qt stack across architectures? > > > > Let me hear your thoughts - I think this could be a significant platform > > win. > > > > BR > > Carsten Munk > > > > [1] http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ > > [2] http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf > > [3] http://www.chromium.org/nativeclient/pnacl > > _______________________________________________ > > MeeGo-dev mailing list > > [email protected] > > http://lists.meego.com/listinfo/meego-dev > > http://wiki.meego.com/Mailing_list_guidelines > > > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
