Check those modules that aren't part of the python installation and bail out
of meson where they're missing. This is technically wrong because we don't
need them at build-time and only at run-time but pragmatically sensible
because we waste too much time dealing with those bugs.
Fixes#200
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As a <builddir>/tuhi and <builddir>/tuhi.devel version. The latter runs
in-tree, the former is the one to be installed.
This is this type of script for a number of reasons. The quickest integration would
be to just use multiprocessing and call into the python module instead of
running other generated scripts. But that doesn't work, GLib doesn't like that
much (the GTK UI crashes). See
https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html
Another option would be to have a single thread because with GObjects we don't
need to care, right? Except that we do because the DBus bindings use sync
calls and that hangs when we have the server in the same process in a single
thread. Fixing the bindings is a bit more involved.
So meanwhile, let's just go for a script that executes the right targets as
separate processes and let the kernel take care of 'threading', that's what
it's there for after all.
Drop the user-visible separation, make everything just Tuhi. Directory
structure remains largely separate (tuhi vs tuhigui) except for the po files
which are in the top-level directory because convention.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer