Re: [Duplicity-talk] Duplicity 1.0.1 Released

[Scott Hannahs]

Ken,

I am sure I am confused!  Thanks for the pointers setting me straight.

But your comment made me realize that I had competing versions of python here.  I have now adjusted things so that it should always be using Python 3.8.13 by replacing references to "/usr/bin/env python3” to “/opt/sw/bin/python3.8” which is my target version of python.  I may try upgrading to python3.10 sometime in the indefinite future.

This now builds "_librsync.cpython-38-darwin.so” and moves it to the duplicity directory.  However, I am still having issues with the tests.  They seem unable to load the _rsyncmodule.

By finding and substiting python3.8 for all the /bin/env python3 lines, it now passes the tests as it should and builds the deb package.

Thanks for your help.  Sorry about my confusion on which python I was running!

-Scott

On Oct 17, 2022, at 11:22 AM, Kenneth Loafman <kenneth@loafman.com> wrote:

Scott,

I think you are confused.

When I refer to _librsync.so it is really _librsync.cpython-39-darwin.so that I'm referring to.  The middle part will change depending on which python and its version it's compiled against.  And no, _librsyncmodule.o is not needed at all once the compile and link have finished.  The build directory is strictly transitory.

librsync is a requirement for duplicity.  See README.md.  So yes, testing would fail, but setup would fail before that.

_librsyncmodule.c is the C interface to librsync.so in the system libraries.  It is compiled and linked against the system librsync.so producing duplicity/_librsync.so as a shim to the library.  On most systems, both /usr/lib and /usr/local/lib are in the path for linker.  On the Mac and some other systems, only /usr/lib is in the path for the linker, thus we add LIBRSYNC_DIR during setup to account for that.  This is passed to setup.py to add extra dirs to link against and include in compiles.  

...Ken