The C code is from Christian Weisgerber, I merely reordered the OSes.
Then I added the build system checks without testing them.
Also thanks to Brad Smith who submitted a similar patch on GitHub
a few hours after Christian had sent his via email.
Co-authored-by: Christian Weisgerber <naddy@mips.inka.de>
Closes: https://github.com/tukaani-project/xz/pull/125
This way the version string gets into xzgrep and other scripts
in full and also into liblzma.pc.
For the project() command, a suffixless string is required though.
liblzma_VERSION has never existed in the repository. xz_VERSION from
the project() command was used for liblzma SOVERSION so use xz_VERSION
here too.
The wrong variable did no harm in practice as PROJECT_VERSION
was used as the fallback. It has the same value as xz_VERSION.
Fixes: 7e3493d40e
This is a mess because liblzma DLL outside Cygwin and MSYS2
is liblzma.dll instead of lzma.dll to avoid a conflict with
lzma.dll from LZMA SDK.
On Cygwin the name was "liblzma-5.dll" while "cyglzma-5.dll"
would have been correct (and match what Libtool produces).
MSYS2 likely was broken too as it uses the "msys-" prefix.
This change has no effect with MinGW-w64 because with that
the "lib" prefix was correct already.
With MSVC builds this is a small breaking change that requires developers
to adjust the library name when linking against liblzma. The liblzma.dll
name is kept as is but the import library and static library are now
lzma.lib instead of liblzma.lib. This is helpful when using pkgconf
because "pkgconf --msvc-syntax --libs liblzma" outputs "lzma.lib"
(it's converted from "-llzma" in liblzma.pc). It would be easy to
keep the liblzma.lib naming but the pkgconf compatibility seems worth
it in the long run. The lzma.lib name is compatible with MinGW-w64
too as -llzma will find also lzma.lib.
vcpkg had been patching CMakeLists.txt this way since 2022 but I
learned this only recently. The reasoning for the patch makes sense,
and while this is a small breaking change with MSVC, it seems like
a decent compromise as it keeps the DLL name the same.
2022 patch in vcpkg: 0707a17ecf/ports/liblzma/win_output_name.patch
See the discussion: https://github.com/microsoft/vcpkg/pull/39024
Thanks to Vincent Torri for confirming the naming issue on Cygwin.
The ancient /bin/tr on Solaris doesn't support '\n'.
With /usr/xpg4/bin/tr it works but it might not be in PATH.
Another problem was that sed was given input that didn't have a newline
at the end. Text files must end with a newline to be portable.
Fix both problems:
- Handle multiline input within sed itself to avoid one tr invocation.
The default sed even on Solaris does understand \n.
- Use octals in tr -d. \012 works for ASCII "line feed", it's even
used as an example in the Solaris man page. But we must strip
also ASCII "carriage return" \015 and EBCDIC "next line" \025.
The EBCDIC case got handled with \n previously. Stripping \012
and \015 on EBCDIC system won't matter as those control chars
won't be present in the string in the first place.
An awk-based solution could be an alternative but it might need
special casing on Solaris to used nawk instead of awk. The changes
in this commit are smaller and should have a smaller risk for
regressions. It's also possible that version.sh will be dropped
entirely at some point.
There's no real value in doing it via commit for official GH actions. We
can keep using pinned commits for unofficial actions. It's hassle for no
gain.
Maybe going forward we can limit this further by only being paranoid
for the jobs with any access to tokens.
Solaris' GCC can't understand that our use is fine, unlike modern compilers:
```
list.c: In function 'print_totals_basic':
list.c:1191:4: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
uint64_to_str(totals.files, 0));
^~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
It's presumably because of older gettext missing format attributes.
This is with `gcc (GCC) 7.3.0`.
In the past this wasn't done before releases; the Git repository
just contained the files from the Translation Project. But this
way it is clearer when comparing release tarballs against the
Git repository. In future releases this might no longer be necessary
within a stable branch as the .po files won't change so easily anymore
when creating a tarball.
When po/xz.pot doesn't exist, running "make" or "make dist" will
create it. Then the .po files will be updated but only if they
actually would change more than the POT-Creation-Date line.
Then the .gmo files would be generated from the .po files.
This is the case before and after this commit.
However, "make dist" and thus "make mydist" did a forced update
to the files, updating them even if the only change was the
POT-Creation-Date line. This had pros and cons: It made it clear
that the .po file really is in sync with the recent strings in
the package. On the other hand, it added noise in form of changed
files in the source tree and distribution tarballs. It can be
ignored with something like "diff -I'^"POT-Creation-Date: '" but
it's still a minor annoyance *if* there's not enough value in
having the most recent timestamp.
Setting DIST_DEPENDS_ON_UPDATE_PO = no means that such forced
update won't happen in "make dist" anymore. However, the "mydist"
target will use xz.pot-update target which is the same target that
is run when xz.pot doesn't exist at all yet. Thus "mydist" will
ensure that the translations are up to date, without noise from
changes that would affect only the POT-Creation-Date line.
Note that po4a always uses msgmerge with --update, so POT-Creation-Date
in the man page translations is never the only change in .po files.
In that sense this commit makes the message translations behave more
similarly to the man page translations.
Distribution tarballs will still have non-reproducible POT-Creation-Date
in po/xz.pot and po4a/xz-man.pot but those are just two files. Even they
could be made reproducible from a Git timestamp if desired.
The .po files from the Translation Project come with unwrapped
strings so this matches it.
This may reduce the noise in diffs too. When the beginning of
a paragraph had changed, the rest of the lines got rewrapped
in msgsid. Now it's just one very long line that changes when
a paragraph has been edited.
The --add-location=file option was removed as redundant. The line
numbers don't exist in the .pot file due to --porefs file and thus
they cannot get copied to the .po files either.
Names from git ls-files should be safe but if one runs it on
a tree without the .git dir and there are extra files, it's
safer to have the end of arguments marked with '--'.
This way the PO file diffs are less noisy but the locations of the
strings are still present at file level, just without line numbers.
The option is available since gettext 0.19 (2014).
configure.ac requires 0.19.6.
Since the source strings have changed, these would get marked as
fuzzy and the original string would be used instead. The original
and translated strings are identical in this case so it wouldn't
matter. But patching the translations helps still because then
po4a will show the correct translation percentage.
One has to pass -DENABLE_X86_ASM=ON to cmake to enable the
CRC assembly code. Autodetection isn't done. Looking at
CMAKE_SYSTEM_PROCESSOR might not work as it comes from uname
unless cross-compilation is done using a CMake toolchain file.
On top of this, if the code is run on modern processors that support
the CLMUL instruction, then the C code should be faster (but then
one should also be using a x86-64 build if possible).
In mydist the point is to check using the file list from the Git
repository. In dist-hook it is to check that the TARBALL_IGNORE
patterns work when the .git dir or the "git" command aren't available.
Refuse to create a distribution tarball if license issues are found.
This helps in spotting files that lack SPDX license identifier
and which haven't been explicitly white listed either. The script
requires the .git directory to be present as only the files that
are in the Git repository are checked.
XZ Utils isn't FSFE REUSE compliant for now.
The po4a directory is in EXTRA_DIST and thus all files there
are included in the package. .gitignore doesn't belong in the
package so keep that file out of the po4a directory.
Now the test scripts detect both
#define HAVE_DECODER_ARM
#define HAVE_DECODER_ARM 1
as support for the ARM filter without confusing it with these:
#define HAVE_DECODER_ARM64
#define HAVE_DECODER_ARM64 1
Previously only the ones ending with " 1" were accepted for
the macros where this kind of confusion was possible.
This should help with Meson support because Meson's built-in
features produce config.h entries that are either
#define FOO 1
#define FOO 0
or:
#define FOO
#undef FOO
The former method has a benefit that one can use "#if FOO" and -Wundef
will catch if a #define is missing (for example, it helps catching
typos). But XZ Utils has to use the latter since it has been
convenient with Autoconf's default behavior.[*] While it's easy to
emulate the Autoconf style (#define FOO 1 vs. no #define at all)
in Meson, it results in clumsy code. Thus it's better to change
the few places in the tests where this difference matters.
[*] While most checks in Autoconf default to the second style above,
a few things use the first style (like AC_CHECK_DECLS). The mix
of both styles is the most confusing as one has to remember which
macro needs #ifdef and which #if. Currently HAVE_VISIBILITY is
only such config.h entry that is 1 or 0. It comes unmodified
from Gnulib's visibility.m4.
Lasse Collin
Sam James
Christoph Junghans
Andrew Murray