Align include documentation to new logic

Commit 2077900b4e was wrong in claiming that the documentation already
demanded repo-relative paths for local includes. It only did that for
dictionary-based include entries. Aligning both to repo-relative paths
remain a value, but we definitely have to update the documentation now.

While at it, also update the code comments accordingly. That also still
talked about the repo key being option, something that was never the
case in practice.

Reported-by: Daniel Wagenknecht <dwagenknecht@emlix.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This commit is contained in:
Jan Kiszka 2021-10-01 10:52:31 +02:00
parent 08631e428f
commit 50e2d2d0fa
2 changed files with 9 additions and 11 deletions

View File

@ -263,7 +263,8 @@ Configuration reference
from every included file. An item in this list can have one of two types:
* item: string
The path to a kas configuration file, relative to the current file.
The path to a kas configuration file, relative to the repository root
of the current file.
* item: dict
If files from other repositories should be included, choose this
@ -274,7 +275,8 @@ Configuration reference
needs to be defined in the ``repos`` dictionary as ``<repo-id>``.
* ``file``: string [required]
The path to the file relative to the root of the repository.
The path to the file, relative to the root of the specified
repository.
* ``build_system``: string [optional]
Defines the bitbake-based build system. Known build systems are

View File

@ -114,14 +114,11 @@ class IncludeHandler:
key containing a list of includes.
The includes can be specified in two ways: as a string
containing the relative path from the current file or as a
dictionary. The dictionary should have a 'file' key containing
the relative path to the include file and optionally a 'repo'
key containing the key of the repository. If the 'repo' key is
missing the value of the 'file' key, it is treated the same as if
just a string was defined, meaning the path is relative to the
current config file. Otherwise it is interpreted relative to
the repository path.
containing the path, relative to the repository root from the
current file, or as a dictionary. The dictionary must have a
'file' key containing the path to the include file and a 'repo'
key containing the key of the repository. The path is interpreted
relative to the repository root path.
The includes are read and merged from the deepest level upwards.
"""
@ -155,7 +152,6 @@ class IncludeHandler:
header:
includes:
- include1.yml
- file: include2.yml
- repo: repo1
file: include-repo1.yml
- repo: repo2