Potential for lzma dependency avoidance.

[jkbonfield]

A reminder to my future self, or to inspire others with time on their hands. :-)

An htslib built without finding xz-utils / lzma library is possible, with appropriate configure opts, but this limits potential compatibility with valid files (albeit currently rare). Maybe we could just include an lzma decoder to use in such circumstances so lzma CRAM can still be decoded even if htslib cannot create new ones.

Not high priority as the easy win is simply to require people to use the official library. However I didn't realise how short such code could be. See https://github.com/Shelwien/lzma_sh

The official version from lzma author is LzmaSpec.cpp, 715 lines including main and file I/O. That's public domain. The shortest version there is just 228 lines (still including main and file I/O), but is GPLed. All appear to work. We'd need to de-C++ them, but it demonstrates that at the heart of it the decode format is relatively straight forward.

I've seen very short (~200 line of JavaScript) bz2 decoders too.

[kalikaneko]

might come useful - the c implementation, public domain https://android.googlesource.com/platform/external/lzma/+/baa3858d3f5d128a5c8466b700098109edcad5f2/C/LzmaDec.c

i could try my hand at this

[jkbonfield]

There are newer versions of that file. The lzmaspec.cpp contained in the git repo I linked above is dated 2015, and a quick google search finds some newer still. Eg this: https://zdoom.org/gitview/311259b0f/lzma/C/Lzma2Dec.c

I'm sure there are many more out there. (Note the master LZMA source is also stated to be public domain, hence why these are following the same license.)

One question I'd have though is how efficient is it? If it's small, but slow, then offering people to ability to compile without lzma support is just leading people into a pitfall. They'll take the easy route without potentially realising the penalty. I'd want to see side by side assessments first.

I'd also argue that largely it's futile. I don't know of anyone using LZMA in CRAM without also enabling bzip2. People tend to use neither, but if anyone is going to go as far as lzma they'll also certainly also include bzip2 as it's faster. Hence lzma alone isn't that helpful. There are standalone bzip2 decoders (eg minibzip2 from http://landley.net/code/, but note license, and https://github.com/antimatter15/bzip2.js/blob/master/bzip2.js in JavaScript).

There's merit in having independence from the libraries, but realistically I don't think it's a high priority thing and it'd come with quite a few pitfalls to work around.