Re: More (de)compress?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 19 Aug 2013 16:17:46 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> 
> Inspired by current decompress.c, I would like to propose the symmetric
> compress function(s) as well as support for more compression methods.
> This is what I have now, and basically it works; still needs MS-Windows
> support, better error detection and a few other things.

What kind of Windows support do you think is needed?  Are you thinking
about dynamic loading (which is a nice-to-have feature), or about
something else?

> +  ### mingw32 doesn't use -lbz2, since it loads the library dynamically.
> +  if test "${opsys}" = "mingw32"; then
> +     LIBBZ2=
> +  fi

This will only work if you implement dynamic loading for libbz2.
Otherwise, Emacs will fail to link, because you call libbz2 functions,
but don't us -lbz2 on the link command line.

> +  ### mingw32 doesn't use -llzma, since it loads the library dynamically.
> +  if test "${opsys}" = "mingw32"; then
> +     LIBLZMA=
> +  fi

Likewise.

> -	profiler.o decompress.o \
> +	profiler.o decompress.o compress.o \

Why do we need both decompress.c and compress.c?  The latter covers
the same ground as the former, no?

More generally, if this is a real submission (as opposed to just a
POC), then I really don't understand where is this going.  E.g., do
you intend to use these primitives, when they are available, in
preference to jka-compr?  If so, why aren't there changes to that
package as part of the changeset?  Likewise for info.el, where it uses
external programs to decompress compressed Info files.

If you do not intend to bypass jka-compr etc., then I must ask what
are the use cases for these primitives, and whether they are different
from those of jka-compr?