Closed jonathanunderwood closed 8 years ago
This PR now supercedes PR #37, PR #35, and PR #40.
@steeve Can you merge this PR? I would like to use an updated version of python-lz4 in some python modules.
@steeve: what can we do to help you merge this?
FWIW: I've been running this new code without any problems for weeks now, and have even built what I have called "0.8.0-rc1" packages for all supported versions of Fedora and CentOS without problems (see http://xpra.org/beta/ )
I should also add that these patches are all in the Fedora package, and so have undergone wide testing there too. It would be very helpful to get this PR integrated and roll a new release if possible.
@steeve I guess you're busy with other stuff, but some feedback on how we can move this forward would be really helpful when you do find time.
Bump! (that's almost 6 months without a reply) In the meantime, I have put a 0.8.0-rc1 tarball here to make it easier to build on all our platforms (RPMs, OSX, win32, etc): http://xpra.org/src/python-lz4-0.8.0-rc1.tar.xz
This branch adds the capability to setup.py to build against a system wide installed lz4 shared library if found, otherwise it'll build with the bundled lz4 files as has been historically done.
The LZ4_VERSION string is only set if building against the bundled library files - the system lz4 library could change at any time, so it's meaningless to statically define this at build time if we're building against a system shared lz4 library.
We also add a new function (lz4version) which returns the lz4 C library version currently in use whether the bundled or system shared library is in use.
Note that lz4version returns the proper lz4 version which is canonical, and distinct from the release version number (r129 or whatever) that is isued for setting LZ4_VERSION.
LZ4_VERSION is brittle and probably shouldn't really be there, but I haven't removed it at this point.