[PATCH weston v5 6/6] Adding doxygen setup and info for the testing framework.

[Pekka Paalanen]

On Sat, 20 Jun 2015 15:47:48 -0700
"Jon A. Cruz" <jonc at osg.samsung.com> wrote:

> Signed-off-by: Jon A. Cruz <jonc at osg.samsung.com>
> ---
>  .gitignore                    |  2 +
>  doc/doxygen/devtools.dox      | 55 ++++++++++++++++++++++++++++
>  doc/doxygen/tooldev.doxygen   | 11 ++++++
>  doc/doxygen/tools.dox         | 32 ++++++++++++++++
>  doc/doxygen/tools.doxygen     | 11 ++++++
>  doc/doxygen/tools_arch_new.gv | 85 +++++++++++++++++++++++++++++++++++++++++++
>  doc/doxygen/tools_arch_old.gv | 53 +++++++++++++++++++++++++++
>  7 files changed, 249 insertions(+)
>  create mode 100644 doc/doxygen/devtools.dox
>  create mode 100644 doc/doxygen/tooldev.doxygen
>  create mode 100644 doc/doxygen/tools.dox
>  create mode 100644 doc/doxygen/tools.doxygen
>  create mode 100644 doc/doxygen/tools_arch_new.gv
>  create mode 100644 doc/doxygen/tools_arch_old.gv

Hi Jon,

this patch seems like a skeleton for adding docs. Have you hooked any
of this up to the build?

How should I build these docs to see how they look like? Nowadays I'm
doing out-of-tree builds on Weston.


Comments for the whole series:

How should I be trying to run the new tests? None of them are hooked up
to 'make check' yet, right?

Oh, config-parser is, but what about waycheck? Is waycheck something
intended to be run?

I see config-parser.test.log, nothing to complain about there.

I tried
$ ./config-parser.test --zuc-output-tap
$ ./config-parser.test --zuc-output-xml
but I didn't see anything different from the default. Did I not use it right?

Also I tried
$ ./config-parser.test --zuc-filter='destroy*'
to see and learn how the filters actually work, but that didn't change
anything either?


In addition to all the comments so far, I'd like to see one client test
converted into this new thing, too. That would demonstrate the fixtures
and waycheck better, and give an idea how we'd write simple client
tests.

I think roles-test.c would be a good candidate for the first client
test. I don't think it really needs the weston-test.so plugin, it
should be trivially convertible from create_client_and_test_surface()
to just create_client().

Spawning the compositor would be good to demonstrate. Also, how you
will handle in-compositor tests and tests that need both in-compositor
and client parts. Though, I don't think you have to implement one of
everything right away. I believe we could start landing these bits once
we see how the compositor is spawned for client tests, and no-one
voices any strong objections.

There are things lacking and WIP, but I don't see anything
fundamentally wrong here. Good job.

I wonder, would it make sense to split patch 1 into zunitc and waycheck
patches?

Isn't zunitc pretty complete now? All the remaining new features to add
would be in waycheck and elsewhere?

Since config-parser test does not need anything from waycheck or such,
only zunitc, would it make sense to land zunitc and config-parser test
as the first two patches?


Thanks,
pq