On Mon, 03 Jun 2019 at 14:17:21 +0300, Pekka Paalanen wrote: > For > a test suite, you could use an environment variable to override the > default search path, but for a manual launch that is a bit more > inconvenient.
This is the solution that is generally recommended in the GLib/GTK/GNOME stack whenever installed-tests <https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests> are based on the same programs that are used as build-time tests. When run as a build-time test, the test assumes the environment variables G_TEST_SRCDIR and G_TEST_BUILDDIR are set to the absolute path to the source and build directories (the $srcdir and $builddir in Automake, or the equivalents in CMake/Meson/etc.). You can use g_test_build_filename() to construct paths to subdirectories of the source or build directory. The build system (Automake, CMake, Meson etc.) is responsible for setting those environment variables (and usually others like LD_LIBRARY_PATH, XDG_DATA_DIRS and GI_TYPELIB_PATH) before invoking the build-time tests. When run as an installed test, a test harness can set those variables if desired. Otherwise, g_test_build_filename() looks at dirname(argv[0]), removes a trailing "/.libs" if present, and assumes that this is correct for both G_TEST_SRCDIR and G_TEST_BUILDDIR. A test can also look for a program- or library-specific environment variable (e.g. FLATPAK_BWRAP in Flatpak's tests), use it if set, and otherwise assume that normal/production behaviour is desired (for example, when FLATPAK_BWRAP is not set, Flatpak would typically use /usr/bin/bwrap or /usr/libexec/flatpak-bwrap, depending how it was configured). Look at (for example) GLib, Flatpak, libostree and dbus for some good examples of this approach. If you want to be able to invoke build-time tests by hand without going through the build system ("make check" or similar), you could make the build system generate a "run-test" script that looks something like this: #!/bin/sh set -e export LD_LIBRARY_PATH="/path/to/build/.libs" export GI_TYPELIB_PATH="/path/to/build" export PATH="/path/to/build:$PATH" export G_TEST_SRCDIR="/path/to/source" export G_TEST_BUILDDIR="/path/to/build" exec -- "$@" by substituting variables in a source file that probably looks something like this: #!/bin/sh set -e export LD_LIBRARY_PATH="@builddir@/.libs" export GI_TYPELIB_PATH="@builddir@" export PATH="@builddir@:$PATH" export G_TEST_SRCDIR="@srcdir@" export G_TEST_BUILDDIR="@builddir@" exec -- "$@" and then run something like "./run-test ./my-unit-test --tap". > Maybe > always search in the build dir and hope that it is not found when > properly installed. Please don't do this: it is a potential security vulnerability. If a user compiles your program or library in (for example) /tmp/my-build, and at a later time or on another system an attacker is able to create /tmp/my-build, then the attacker is likely to be able to gain control over your program and execute arbitrary code with the privileges of the user who is running it. > FWIW, Weston uses environment variables for the test suite, and > otherwise requires you to have installed first. This sounds like essentially the same approach that the GNOME stack recommends. smcv _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel