On 2015-05-22 Adam Walling wrote:
> This is a minimal solution and two project files which allow liblzma
> to be built with MSVC2013. I did not attempt to include any tools or
> tests, or address any warnings. However, it is functional, so I would
> like to share this as an alternative to the 'Fairly Complete'
> solution / project.
>
> This does not require any changes to the code itself, just adding the
> files within the /windows subdirectory is enough.
>
> liblzma.vcxproj builds the static library
> liblzma_dll.vcxproj builds a dll
Thanks! This could be a good start since I still think that liblzma is
the important part of XZ Utils to get working with MSVC. xz.exe can wait
a little longer.
There are a few extra files in the build:
- Of the tuklib_*.c files, liblzma only needs tuklib_physmem.c and
tuklib_cpucores.c.
- rangecoder/price_tablegen.c must not be included. It's a standalone
tool to generate price_table.c.
It's nice to see that you got liblzma_w32res.rc to build as is. In the
other thread there were problems with the resource files and using CMake
was considered, but clearly it's not needed at least for liblzma DLL.
Seems that the DLL file becomes liblzma_dll.dll. I wonder if that is a
good thing. As I understand this, the MSVC-built liblzma DLL should be
compatible with the DLL built with MinGW-w64 so naming it just
liblzma.dll should be more convenient, but perhaps I'm missing
something.
With the above issues fixed, I could like to commit the project files
and include them in XZ Utils 5.2.2. This doesn't make the other MSVC
thread deprecated yet: I should fix a few more warnings, and perhaps
xz.exe could be made MSVC compatible some day too.
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
