This makes it more convenient to compile them alongside SDL, install
them in an optional package and use them as smoke-tests or diagnostic
tools. The default installation directory is taken from GNOME's
installed-tests, which seems as good a convention as any other:
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
Signed-off-by: Simon McVittie <smcv@collabora.com>
There are two issues which are stopping the SDL tests from building on
my machine:
- libunwind is not being linked
- Even if it is, it is missing several symbols.
The first is fixed by having the test programs link against libunwind if
available. Technically, SDL2_test should be linking against it, as it's
used in SDL_test_memory.c, but as SDL2_test is a static library, it
can't itself import libunwind. We just assume that if it's present on
the system, we should link it directly to the test programs. This should
strictly be an improvement, as the only case where this'd fail is if
SDL2 was compiled when libunwind was present, but the tests are being
compiled without it, and that'd fail anyway.
The second is fixed by #define-ing UNW_LOCAL_ONLY before including
libunwind.h: this is required to make libunwind link to predicatable
symbols, in what can only be described as a bit of a farce. There are a
few more details in the libunwind man page, but the gist of it is that
it disables support for "remote unwinding": unwinding stack frames in a
different process (and possibly from a different architecture?):
http://www.nongnu.org/libunwind/man/libunwind(3).html
Note that I haven't tried this with CMake: I suspect that it'll work,
though, as the CMakeLists.txt seems to have SDL2 link against libunwind if
it's present. This adds an ugly extra dependency to SDL2, but does mean
that issue 1 isn't present. The UNW_LOCAL_ONLY change shouldn't be
build-system-specific.
AC_CONFIG_AUX_DIRS is an undocumented, internal version of
AC_CONFIG_AUX_DIR that takes a whitespace-separated list, instead of a
single path to add to the list. It also does not automatically treat
the given path as being relative to the $srcdir, unlike the documented
AC_CONFIG_AUX_DIR.
Newer versions of autoconf treat the argument to AC_CONFIG_AUX_DIRS
as being literal (they do not expand the shell variable), causing
autoreconf to fail if $srcdir is explicitly specified. The argument to
AC_CONFIG_AUX_DIR is checked relative to $srcdir anyway, so there is no
need to specify $srcdir a second time.
Resolves: https://github.com/libsdl-org/SDL/issues/4719
Signed-off-by: Simon McVittie <smcv@debian.org>
configure output is practically unchanged. there are still lots of
AC_TRY_COMPILE/AC_TRY_LINK replacements needed to really eliminate
the warnings, but that's for another time.
