On Sun, 2008-07-13 at 22:46 -0500, Daniel Drake wrote: > Bastien Nocera wrote: > >> - removing glib dependency (or at least making steps in that direction) > > > > Is that such a good idea? I'd rather we used it more, especially as we > > want developers to be using the fprintd D-Bus service in the future, > > which will be using glib in any case. What's the reasoning behind that? > > I'm only talking about removing the dep from libfprint, fprintd can > still use glib.
I figured that. > The reason is that people want to run libfprint on embedded devices > where glib is too heavy. You can disable regex, SELinux and threads support, which should bring down the size of glib. This is the size on my machine with regex enabled, on a 64kB machine. $ ll /lib64/libglib-2.0.so.0.1600.3 926k -rwxr-xr-x 1 root root 918k 2008-06-17 04:48 /lib64/libglib-2.0.so.0.1600.3 > I myself have an embedded MIPS device with > embedded DigitalPersona fingerprint reader and a whopping 4mb of > storage. It runs proprietary DigitalPersona software and is a useful > device (see > http://www.disbio.com/index.php?/Contenido/Control-de-Presencia.html for > a successful commercial application). > It would be great to replace the software with libfprint, but there is > not enough room for glib. How big did glib end up being on your MIPS platform? > Other people ran into the exact same issues on other setups. > > Which features of glib are you thinking would be useful here? I > initially though glib would be a major boost for development and we'd > use it so much it would be difficult to remove. But actually we don't > really use much at all. You mentioned wanting to make reader drivers selectable at compile time. You could use GModule and make them all plugins, and include some of them directly in the library binary, as GModule supports (using NULL as the filename to g_module_open). It also hides a lot of stupid unix-y differences, runs on Windows, and gives you a lot of useful convenience data types. You could also use GSources to handle polling better in libfprint. You could also kill more bits of libfprint such as aeslib.c when it's not used by any compiled drivers. > >> - standardising error codes > >> - making driver inclusion configurable at configure-time (then > >> separating out dependencies by driver e.g. only aes4000 requires > >> ImageMagick) > > > > This should be pretty easy. See Totem's configure.in to select the > > plugins: > > http://svn.gnome.org/viewvc/totem/trunk/configure.in?view=markup > > Look for "Movie player plugins". > > Agreed :) Cheers _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
