Using libweston with GTK/GDK

[Simon McVittie]

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