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

[Emil Velikov]

On 13 February 2018 at 17:46, Daniel Stone <daniel at fooishbar.org> wrote:
> 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?
>
Pardon for the delay, Dan.
While Emre has already resolved the issue, let me add a couple words
more to my earlier, cryptic, email:

 - threading
I could not spot any, although the behaviour that you described
sounded like an in-weston race condition.
We now know that wasn't a race, but a layering confusion/violation(?).
 - missing dependencies [in the Makefile.am]
I didn't explicitly check if all the files (binaries and configs) are
correctly annotated, hence present before the tests were run.


On the testrunner side - I've used cmocka and it seemed rather nice.
I liked the exception handling for signals, it has no templates plus
valgrind was always happy.

HTH
Emil

[1] https://api.cmocka.org/