osx provides dylib for lzma to bind, but no headers

[cartazio]

would be awfully nice to work around that catastrophy :)

cc @hvr @hasufell @bgamari

[bgamari]

I think it would be best if the lzma followed the lead of zlib and bundled the C sources for Windows and other platforms lacking the package. The interesting bits of xz-utils appears to be public domain so I don't expect there would be any licensing issues here.

[bgamari]

Actually, it looks like lzma already does this on Windows via the lzma-clib package. Unfortunately, this package is only buildable on Windows due to the use of a hard-coded autoconf configuration. It's unclear why we can't just run autoconf. I suspect that the reason may be licensing.

[hasufell]

haskell-hvr/lzma-clib#2

[hvr]

@bgamari marai What licensing (incompatibility?) issues would there even be? It was purely due to technical reasons to not require autoconf on Windows where it's most often redundant as there's little to probe on Win32 anyway.

Also note that zlib only uses its internal when os(windows) -- so lzma is acting quite similar to zlib here -- you can't force zlib to use its internal c-code (which avoids autoconf too) on non-windows.

However, there's an easy way to have lzma-clib be autoconf-enabled for non-windows and autoconf-disabled for non-windows which I had already anticipated in case I needed this for any of the packages where I use the *-clib pattern.

[bgamari]

@bgamari What licensing (incompatibility?) issues would there even be?

Yes, I was thinking of incompatibility but I don't believe this should be a problem.

However, there's an easy way to have lzma-clib be autoconf-enabled for non-windows and autoconf-disabled for non-windows which I had already anticipated in case I needed this for any of the packages where I use the *-clib pattern.

Lovely. It would be great to enable this for Darwin.