On 13 February 2018 at 16:37, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> The following two questions come to mind:
> - app bugs - using threads? ivi-shell-user-interface.c mentions
> pthread, but haven't looked closely
Hm, I couldn't find any threading-related bugs at all: everything I
found was clear just looking at the inter-process flows. Did you have
anything in particular in mind?
> - missing dependencies
Again, did you have anything in particular in mind? Looking at the
logs, it loads the exact same set of plugins/helpers/configs in both
cases (working/broken). Dumping out /proc/self/smaps didn't show any
discrepancies either. Everything was fresh and up-to-date: it's seems
like it's only the test execution environment which influences this.
> Having a look reveals:
> - extremely convoluted test runner
Sure. We had a few requirements which led to the runner being the way
it was, mainly based on it being relatively easy to write tests, and
assertion failures / segfaults not destroying the whole testsuite.
Personally I like igt, and I guess others like gtest or maybe Piglit,
but none of them are anything like simple. Do you have a good
replacement in mind?
(Whilst we're mentioning test runners and threads, I really wouldn't
mind one which ran everything in threads rather than forking
> - dummy BACKEND variable - always headless-backend.so
It's not a dummy: you can run 'make check BACKEND=foo-backend.so' as a
developer, if you'd like to test a particular backend. Most of them
are totally unsuitable for general-purpose use (e.g. wayland-backend
or x11-backend will pop up a billion windows as it goes about its
work, and that rapid de/focus can in fact break some tests), so we
default to headless-backend for mere mortals. But it is there as an
option for people who know what they're doing, or want to try tests in
a different context.
> - the --backend, --config, --shell and/or --modules file is not part
> of the respective dependency chain
The checks here are only run as part of the 'check' target; check
depends on check-am, which in turn depends on the all-am target, which
in turn depends on all libraries/programs/built-sources, which covers
all of the items you've mentioned. Is there some subtlety I'm missing
wayland-devel mailing list