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