On Jan 25, 2010, at 18:06 , Alon Bar-Lev wrote: > On Mon, Jan 25, 2010 at 9:07 AM, Andreas Jellinghaus <a...@dungeon.inka.de> > wrote: >> Am Sonntag 24 Januar 2010 21:45:07 schrieb Alon Bar-Lev: >>> If it is imported from other place, why not just link against it? >> >> what do you exactly propose? >> create a second noinst_ lib in common/ and link it in opensc/ the same >> way we include libcompat.a? fine with me. > > No... if the code was copied out of some other project, link against > that project... Not everything is "projectized" (incl simclist). There's a good reason sqlite provides a sqlite.c you just put into your project and voila, you get the sqlite functionality. It does have some drawbacks but at the same time it avoids library-messs for users and provides ease of use (in this case, to developers)
> >> for the implementation: we could simply make the libs we have so far >> "noinst_" libs, and then in pkcs15init/ directory create one huge >> lib with all parts (except pkcs#11), and link opensc-pkcs11 with that, >> or create the big lib in pkcs11/ directory (then containing all >> parts). in tool/ we will need to change the linking, so no "noinst" >> lib is referenced, but only the shared lib we want to install. >> haven't tested that, but it should work that way, I guess. That's something I have in mind as well, not sure if/how this should work out in practice. - libopensc (with all siblings, scconf, common/compat, pkcs15init in it) - tools that use libopensc - pkcs11 module that uses libopensc -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
