GitLab

"make dist" updates the .po files and the fuzzy strings would
result in multiple very wrong translations.

I made a few minor white space changes without getting them
approved by the Danish translation team.

DJGPP 2.05 added support for thousands separators but it's
broken at least under WinXP with Finnish locale that uses
a non-breaking space as the thousands separator. Workaround
by disabling thousands separators for DJGPP builds.

It doesn't need -fgnu89-inline like 2.04beta did.

The added defines assume GCC >= 4.8.

I made a few white space changes to these without getting them
approved by the translation teams. (I tried to contact the hu and
zh_TW teams but didn't succeed. I didn't contact the zh_CN team.)

The translated strings haven't been updated but word wrapping
is different.

The German translation isn't identical to the file in
the Translation Project but the changes (white space changes
only) were approved by the translator Mario Blättermann.

This version matches CMake files in the master branch (commit
5e1a1e568976) except that this omits
two source files that aren't in v5.2 and in the beginning of
CMakeLists.txt the first paragraph in the comment is slightly
different to point out possible issues in building shared liblzma.

Normally, if po4a isn't available, autogen.sh will return
with non-zero exit status. The option --no-po4a can be useful
when one knows that po4a isn't available but wants autogen.sh
to still return with zero exit status.

This file only generates fastpos_table.c.
It isn't built as a part of liblzma.

This should silence the equivalent of -Wundef in compilers that
don't define __GNUC__.

This gives a tiny encoder speed improvement. This could have been done
in 2014 after the commit 37ea94ad77e0 but
it was forgotten.

Appears that this file used to get included as a side effect of
gettext. After the change to gettext version requirements this file
no longer got copied to the package and so the build was broken.

It can be true at least on z/OS.

The __builtin byteswapping is the preferred one so check for it first.

strerror() needs <string.h> which happened to be included via
tuklib_common.h -> tuklib_config.h -> sysdefs.h if HAVE_CONFIG_H
was defined. This wasn't tested without config.h before so it
had worked fine.

string.h is used unconditionally elsewhere in the project and
configure has always stopped if limits.h is missing, so these
headers must have been always available even on the weirdest
systems.

There is no specific reason for this other than blocking
the most ancient versions. These are still old:

Autoconf 2.69 (2012)
Automake 1.12 (2012)
gettext 0.19.6 (2015)
Libtool 2.4 (2010)

This bumps the version requirement from 0.19 (from 2014) to
0.19.6 (2015).

Using only the old AM_GNU_GETTEXT_VERSION results in old
gettext infrastructure being placed in the package. By using
both macros we get the latest gettext files while the other
programs in the Autotools family can still see the old macro.

Thanks to Mario Blättermann.

The dependency on po4a is optional. It's never required to install
the translated man pages when xz is built from a release tarball.
If po4a is missing when building from xz.git, the translated man
pages won't be generated but otherwise the build will work normally.

The translations are only updated automatically by autogen.sh and
by "make mydist". This makes it easy to keep po4a as an optional
dependency and ensures that I won't forget to put updated
translations to a release tarball.

The translated man pages aren't installed if --disable-nls is used.

The installation of translated man pages abuses Automake internals
by calling "install-man" with redefined dist_man_MANS and man_MANS.
This makes the hairy script code slightly less hairy. If it breaks
some day, this code needs to be fixed; don't blame Automake developers.

Also, this adds more quotes to the existing shell script code in
the Makefile.am "-hook"s.

I don't know if the problem is in gnulib's gl_POSIX_SHELL macro
or if xzgrep does something that isn't in POSIX. The workaround
adds a special case for Solaris: if /usr/xpg4/bin/sh exists and
gl_cv_posix_shell wasn't overriden on the configure command line,
use that shell for xzgrep and other scripts. That shell is known
to work and exists on most Solaris systems.