Using libweston with GTK/GDK
smcv at collabora.com
Mon Jun 3 11:39:09 UTC 2019
On Mon, 03 Jun 2019 at 14:17:21 +0300, Pekka Paalanen wrote:
> 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
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),
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:
exec -- "$@"
by substituting variables in a source file that probably looks something
exec -- "$@"
and then run something like "./run-test ./my-unit-test --tap".
> 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
More information about the wayland-devel