[PATCH weston 1/4] ivi-shell: change layer visibility to bool

[Daniel Stone]

Hi Emil,

On 13 February 2018 at 16:37, Emil Velikov <emil.l.velikov at 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
children.)

>  - 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
here?

Cheers,
Daniel