Eric Biggers

Maintaining multiple build systems would be error-prone and extra work. (And I only have time to work in libdeflate in my free time, so anything that avoids introducing additional maintenance...

> ``` > In file included from /home/travis/build/bsergean/libdeflate/lib/adler32.c:63:0: > > /home/travis/build/bsergean/libdeflate/lib/arm/adler32_impl.h: In function ‘adler32_neon_chunk’: > > /home/travis/build/bsergean/libdeflate/lib/arm/adler32_impl.h:102:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] > > *s1 +=...

Given the interest, I'm willing to switch to CMake, but it has to replace the current Makefile instead of being added alongside it.

> At the risk of piling on, but for the record: I for one would likely lose any interest in contributing to libdeflate if it switched from a Makefile to...

I'd like to support streaming, but I'm not sure what the best way to do so is, other than the traditional zlib way. It needs more investigation. I haven't had...

Internals, mostly. I am familiar with zlib's API.

Yes, other options for the API should be considered too.

I don't plan to add streaming support. I think there's no easy way to do it, and it doesn't make too much sense to add it without going all the...

`.lib` appears to be the Windows convention, e.g. see https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-creation#creating-an-import-library. So I'm thinking it shouldn't be changed.

I thought that the point of providing an import library is because Visual Studio requires it in order to link to the DLL. (MinGW does not require it.) So doesn't...