For testing it's a lot easier to just provide a /tmp/ directory than having to
clear out the normal one that may contain useful drawings for debugging.
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.
Peter Hutterer