John Levon wrote: > On Mon, Mar 31, 2008 at 11:36:10AM -0700, Tim S. Knitter wrote: > > >>> - it shouldn't be installed in /usr/lib/, but at the >>> same location as >>> >> It's final destination once installed is >> /usr/lib/python2.4/vendor-packages/beadm. >> > > OK, sounds good - I was being misled by libbe_glue/Makefile, I think. > > >>> other Python modules, namely /usr/lib/python2.4/vendor-packages - it >>> should just be called 'libbe.so' as per other Python modules >>> >> I tried to find a definitive answer to the naming convention for C -> >> Python library wrappers but was unsuccessful. Can you point me to >> where the naming for wrappers is defined and I'll change libbe_glue >> to libbe? >> > > I doubt you'd find anything written down, it's just a de facto standard. > Maybe my point is better raised as a question: what are the reasons > behind creating the new "_glue" convention? >
I don't think there was a reason for _glue. I agree, I think going with a de facto standard is the better way to go. One thing I'm noticing on a current Solaris x86 box is that there seems to be a couple other conventions. Given a /usr/lib/libfoo.so.1, there are a couple cases of /usr/lib/python2.4/vendor-packages/foo.so or /usr/lib/python2.4/vendor-packages/libfoomod.so I don't know if what I'm looking at are wrappers for the original C lib or just helper modules, but are these also commonly used conventions for wrapper libs that we should be considering, or should we just stick with the same named library? > >>> - I haven't looked, but what is the purpose of libbe_glue.h? >>> >> To declare the public functions in libbe_glue.c. Also follows the >> libbe.h convention. >> > > But these functions are only ever called via the Python runtime, no? > That's correct. I think the libbe_glue.h needs to be nuked. > thanks, > john > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
