2011/2/26 Olivier Guilyardi <[email protected]>: > On 02/25/2011 09:13 PM, Stefano D'Angelo wrote: >> 2011/2/25 Olivier Guilyardi <[email protected]>: > >>> That said there is another big problem. This glib dependency, it's way too >>> heavy >>> for mobile deployment. >> >> Since this was already discussed and we happen to have possible GLib >> replacements, could you expand on that? Why is it too heavy? > > Size. There are two bottlenecks related to size when deploying on Android: > > - the space it takes on the device. In the past apps could only be installed > in > the device internal memory, and it is often quite small, like about 150Mb. > People tend to install a lot of apps so this gets filled quickly. So, a > mechanism, app2sd, has been added to allow installing apps on the sdcard, > which > is usually more than 8Gb. But this doesn't work for native libraries, because > the sdcard is mounted noexec. You can use app2sd, but the native libraries > provided by the app are copied to internal memory. > > - the download time. It is common for users to download apps when they're on > the > go, and thus possibly using a bad internet link. > > My app is currently a little less than 1Mb, and I actually don't really want > to > make it bigger. Some games can get big, but my app isn't a game, it's intended > to be lightweight. > > For example, I needed to add a little magic, to detect file formats. So I > grabbed libmagic, compiled that, linked statically, and IIRC it resulted in a > size increase of about 200Kb. That was quite unacceptable for such a simple > functionality. > > So, I read the code and libmagic metadata files, and I implemented my own > magic > (OGG, WAV, FLAC, AIFF, MP3) in about 30 lines of C. I had a couple of bugs, > but > it now works flawlessly. > > That said, I would need to test what kind of size it takes when linking > statically against SLV2. But I will need to support glib as a shared library > or > something like that because of the LGPL. That's a lot of complication. > > This RDF turtle format is surely a beautiful thing when you write or read it, > but it requires such a parsing machinery... > > What about an alternative format intended for lightweight packaging and > parsing? > It would take the turtle metadata and convert it into a text file which could > be > parsed with about 100 lines of C. It may not work for all plugins, but maybe > for > the vast majority of them? > > At least I'm thinking about that kind of solution for packaging for Android. > Some kind of pre-parsing/metadata-simplification at packaging stage to avoid > the > need for bundling a full-fledged parser.
So, the latest SLV2 has dropped librdf in favor of a minimal RDF/Turtle implementation already done by Dave himself. Such implementation is basically made of two libraries: Serd (parser) and Sord (triple store). Here is the size of the current svn SLV2 and its dependencies on my machine (arch linux x86-64), all stripped, yet probably compiled with -02, excluing glib: libslv2 is 61K, libsord is 29K, libserd is 44K, libpcre is 236K (I didn't know it was a dependency, what is it for Dave?). That means: slv2+sord+serd = 134K, adding pcre is 370K. Now, libnacore when stripped is 56K... if it could substitute both pcre and glib, it would mean the whole stack = 190K + something else. Considering that Android platforms are probably 32 bit (right?) and stuff could be compiled with -Os, I would say we would end up somewhere in between 100 to 250K. Is that still too much? Stefano _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
