Personally, I think that it is much more convenient to have separate libraries. Beside the fact that it does not require re-compile to get exact functionality you are looking for, it also makes it easy to mix- match modules, so if you want to use different matching module, all you need to do is to replace appropriate library.
On Jan 14, 2008, at 17:07 , Daniel Drake wrote: > Davidlohr Bueso wrote: >> Currently I am doing major fprint modifications. Removing >> glib/imagemagick, fixing leaks, separating the project into different >> little independent modules. I will have get this proyect working on a >> little ARM machine. Hopefully I will have something ready to show >> soon. > > Please try and divide your changes and submit them incrementally, > otherwise it'll be difficult/impossible to merge your work. (That > said, > things are also likely to slip while I am in exam period, plus I am > spending most of my time working on the new libusb...) > >> The basic idea is that a rather heavy monolithic fprint library is >> separated into smaller, lighter, simpler (usually) independent >> modules >> (libraries actually) that can be used in a wide range of devices and >> architectures (like ARM, microblaze, etc). So, for example, if I >> wanted to implement a matching server, I can use that specific >> lib, and >> not care about enrolling, capturing, etc. > > Interesting idea, but I'm not so sure about the "many libraries" > approach. Have you considered adding a series configure flags to > control > functionality that is built in? e.g. if built with --disable-enroll > then > fp_enroll_finger() simply returns -EOPNOTSUPP and so on. > > Thanks, > Daniel > _______________________________________________ > fprint mailing list > [email protected] > http://lists.reactivated.net/mailman/listinfo/fprint _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
