homepage

> - liblzma can't be compiled by Visual Studio: too many C99 isms,
> mostly variables declared in the middle of a block. It's doable for
> sure, but it's a lot of work.
I'd be in favor of doing so, and then feeding patches upstream.
Hopefully, eventually, the code would compile out of the box on VS.
> - liblzma is normally compiled with mingw, but we have to be sure
> that is uses the correct MSCRT C runtime, and what about debug
> builds?
In principle, it's not necessary to use the same CRT, as long as
we aren't passing CRT objects across DLL boundaries (memory
blocks managed by malloc/free would be candidates). I haven't reviewed
the module to find out whether the liblzma interface involves CRT
objects.
> - The way recommended by XZ is to use a precompiled liblzma.dll; Then
> it should be easy to build an extension module, but its would be the
> first time that we distribute an extension module which needs a
> non-system DLL. Is it enough to copy it next to _lzma.pyd? Is there
> some work to do in the installer?
It wouldn't actually be the first time. We also ship Tcl DLLs. But
it's a pain, so it would be much better if the sources were actually
referenced in the VS project - so we would not need a library at all.