Currently the file list generated by Doxygen has src/ at the
beginning of each path. Paths like common/sysdefs.h and
liblzma/api/lzma.h are easier to read without such a prefix.
Builds from a separate build directory with
mkdir build
cd build
../configure
doxygen Doxyfile
include an even longer prefix /home/someone/src/xz/src; this
patch has the nice side-effect of eliminating that prefix, too.
Fixes: http://bugs.debian.org/572273
The example programs by Daniel Mealha Cabrita were included
in the git repository, but I had forgot to add them to
Makefile.am. Thus, they didn't get included in the source
package at all by "make dist".
This has no semantic changes. I find the new names slightly
more logical and they match the names that are already used
in XZ Embedded.
The name fastpos wasn't changed (not worth the hassle).
If any of the reserved members in lzma_stream are non-zero
or non-NULL, LZMA_OPTIONS_ERROR is returned. It is possible
that a new feature in the future is indicated by just setting
a reserved member to some other value, so the old liblzma
version need to catch it as an unsupported feature.
The non-standard ones from msvcrt.dll appear to work
most of the time with XZ Utils, but there are some
corner cases where things may go very wrong. So it's
good to use the better replacements provided by
MinGW(-w64) runtime.
Calling raise() to kill xz when user has pressed C-c
is a bit verbose on OS/2 and DOS/DJGPP. Instead of
calling raise(), set only the exit status to 1.
This is simply for licensing reasons. The 64-bit version
will be built with MinGW-w64 anyway (at least for now),
so using it also for 32-bit build allows using the same
copyright notice about the MinGW-w64/w32 runtime.
Note that using MinGW would require a copyright notice too,
because its runtime is not in the public domain either even
though MinGW's home page claims that it is public domain.
See <http://marc.info/?l=mingw-users&m=126489506214078>.
Those are the same thing, and the former makes it a bit
easier to build the code with other build systems, because
one doesn't need to update the version number into custom
config.h.
This change affects only lzmainfo. Other tools were already
using LZMA_VERSION_STRING.
Most distros want xz linked against shared liblzma, so
it doesn't help much to require --enable-dynamic for that.
Those who want to avoid PIC on x86-32 to get better
performance, can still do it e.g. by using --disable-shared
to compile xz and then another pass to compile shared liblzma.
Part of these static/dynamic tricks were needed for Windows
in the past. Nowadays we rely on GCC and binutils to do the
right thing with auto-import. If the Autotooled build system
needs to support some other toolchain on Windows in the future,
this may need some rethinking.
