example-application module: add trivial project

[gregshue]

Introduction

The example-application repository is to demonstrate how an external module may be organized and configured so that module features may be configured, built, and verified by the Zephyr build/CI system. This proposal is to add the trivial non-test, non-sample project zxa_trivial_hello as an example demonstrating:

• how non-test, non-sample project trees can be added into modules and found by the config, build, and CI system
• how projects may have rich functionality (and be fully testable) by having an empty void main(void) { }

and to provide a Zephyr Documentation Generation test case where project documentation exists in an external repository.

Problem description

The scope of the example-application module includes demonstrating a way to configure modules so that projects in the module will be recognized by the Zephyr config, build, and CI systems, and be properly handled by the Zephyr Document Generation system.

Proposed change

This solution requires:

• adding a new subtree for non-test, non-sample projects. If necessary, this would be paralleled beneath tests/, but this trivial project would not need that.
• extending zephyr/module.yml so the CI and documentation system recognize the projects tree as a samples or tests tree

The trivial project would contain only the following:

• CMakeLists.txt
• prj.conf
• sample.yml
• src/main.c (with only a copyright, an SPDX license statement, and void main(void) { })
• doc/index.rst (with trivial content used as a test case for Zephyr document generation testing)

Detailed RFC

Proposed change (Detailed)

This is very trivial. See above.

Dependencies

This depends only on the existing Zephyr build system functionality, and possibly on a proposed subsystem in this module.

Concerns and Unresolved Questions

The Zephyr Documentation Generation inconsistently handles documentation in modules. Documentation is generated for Kconfig and interface files in modules, but ignored for projects and boards in modules. Unfortunately the desired behavior is undefined. What is the behavior supposed to be? How can we automatically verify that behavior in the example-application CI?

Alternatives

I considered not providing the documentation in the project, but having it is consistent with the Zephyr tree structure and it is needed for verifying Zephyr document generation behavior (once defined).