2077900b4e
So far, repository paths for local includes were derived from the path name of the config file containing the include, rather than using the actual repository root as specified in the documentation. No one complained so far, some layers simply adjusted their includes to this inconsistency which was only discovered during refactorings. Fix this issue by passing also the repository path along with the config filename down the recursive _internal_include_handler calls. The top-level repo path now needs to be retrieved before the creation of IncludeHandler and passed to it then. This has the side effect of enabling deviating top-level repo paths, a feature that will be used by the upcoming changes for a .config.yaml file in KAS_WORK_DIR. As there are existing users of the old behavior out there, fall back to it if a local include cannot be found under the correct path and warn if this succeeds. This allows smooth migration of layers to the right pattern as they update their kas version. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> |
||
|---|---|---|
| .github | ||
| docs | ||
| kas | ||
| scripts | ||
| tests | ||
| .dockerignore | ||
| .flake8 | ||
| .gitignore | ||
| CHANGELOG.md | ||
| container-entrypoint | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| Dockerfile.isar | ||
| kas-container | ||
| kas-docker | ||
| LICENSE | ||
| README.rst | ||
| requirements_rtd.txt | ||
| run-kas | ||
| setup.py | ||
Setup tool for bitbake based projects ===================================== +--------------------+ | Build Status | +====================+ | |workflow-master|_ | +--------------------+ | |workflow-next|_ | +--------------------+ .. |workflow-master| image:: https://github.com/siemens/kas/workflows/master/badge.svg .. _workflow-master: https://github.com/siemens/kas/actions?query=workflow%3Amaster .. |workflow-next| image:: https://github.com/siemens/kas/workflows/next/badge.svg .. _workflow-next: https://github.com/siemens/kas/actions?query=workflow%3Anext This tool provides an easy mechanism to setup bitbake based projects. The OpenEmbedded tooling support starts at step 2 with bitbake. The downloading of sources and then configuration has to be done by hand. Usually, this is explained in a README. Instead kas is using a project configuration file and does the download and configuration phase. Key features provided by the build tool: - clone and checkout bitbake layers - create default bitbake settings (machine, arch, ...) - launch minimal build environment, reducing risk of host contamination - initiate bitbake build process See the `kas documentation <https://kas.readthedocs.io>`_ for further details.