[DRAFT] bitbake-setup: generate Yocto-native build configs from kas - #235
Open
yoctopidg3 wants to merge 6 commits into
Open
yoctopidg3 wants to merge 6 commits into
yoctopidg3 wants to merge 6 commits into
Conversation
Translate the authoritative kas configuration into bitbake-setup Configuration Templates so AvocadoOS can be set up with the upstream Yocto tooling as well as kas. The script runs `kas dump` offline per kas/machine/*.yml and maps the flattened result: vendor repos -> sources, their layers -> bb-layers, env -> fragment defaults + passthrough, machine/distro/local_conf_header -> an OE config fragment. meta-avocado itself is the local (url-less) repo in kas, so it is emitted as bb-layers-file-relative pointing at the live working tree the configs ship in, rather than a cloned source. The build then uses your checkout directly -- local edits and unpushed commits take effect with no push, matching kas. kas stays the single source of truth; output is deterministic. Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Generated by scripts/kas2bitbake-setup.py from kas/ on the wrynose branch. Vendor sources are pinned to the same wrynose/wrynose-avocado revisions as kas; the meta-avocado layers are referenced in place via bb-layers-file-relative (the live working tree). One avocado-<machine>.conf.json per machine plus the matching meta-avocado/conf/fragments/avocado-build/<machine>.conf. Regenerate after any kas change; output is deterministic. Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
scripts/bitbake-setup wraps the bootstrap bitbake's bitbake-setup and pins the build top directory to meta-avocado/bitbake-builds/, regardless of cwd or the user's global settings (top-dir-prefix/top-dir-name are GLOBAL_ONLY, so they are passed on the command line). This mirrors kas's scripts/init-build convention of keeping build trees inside the checkout. gitignore the two bitbake-setup runtime artifacts: the bootstrap bitbake clone (/bitbake/) and the build trees (/bitbake-builds/). Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Present both setup paths as first-class in the top-level README and add bitbake-setup/README.md with usage, the kas<->bitbake-setup mapping, and regeneration instructions. Cover the one-time bitbake bootstrap clone, driving builds through scripts/bitbake-setup (build trees under meta-avocado/bitbake-builds/), that the meta-avocado layers build from the live checkout (local by default, no push), and that init must be run from a local path. Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
The common-pc / intel-x86 BSP fragments set CONFIG_USB_SERIAL_CONSOLE=y, which hard-depends on USB_SERIAL=y (built-in). AvocadoOS ships USB serial as a module (CONFIG_USB_SERIAL=m), so the console variant is unassignable and silently drops to n -- tripping do_kernel_configcheck with "specified values did not make it into the kernel's final configuration". Explicitly set "# CONFIG_USB_SERIAL_CONSOLE is not set" in the qemu and x86-64 kernel config fragments (applied after the BSP, so ours is the last specified value). A USB-serial console can't work with a module-loaded driver anyway; these targets use the virtio/ttyS console. Verified on avocado-qemux86-64: do_kernel_configcheck succeeds with zero "did not make it" entries; .config keeps CONFIG_USB_SERIAL=m. Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
The wrapper pinned the build top dir under the repo, which also dragged DL_DIR and sstate into meta-avocado/bitbake-builds/ -- tens of GB inside the checkout, and lost on any `rm -rf bitbake-builds`. Point both at a shared external cache (default ~/.cache/avocado-bitbake-setup), overridable via AVOCADO_BB_CACHE / AVOCADO_DL_DIR / AVOCADO_SSTATE_DIR. DL_DIR is passed as a bitbake-setup setting; SSTATE_DIR has no setting (site.conf hardcodes <top_dir>/.sstate-cache), so the wrapper symlinks that path at the external cache. Document the variables in bitbake-setup/README.md. Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Contributor
|
Is there a way to concatenate config fragments as to de duplicate any shared local config settings between target families? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds bitbake-setup as a parallel way to set up AvocadoOS alongside kas. We translate the existing kas configuration into upstream Yocto bitbake-setup configuration templates, so the same build can be driven by either tool and the two never drift. Also includes a build-tree/cache layout for the wrapper and one kernel-config fix.
kas remains the canonical setup mechanism, but for grumps like me, we can still use bitbake-setup.
Generator (scripts/kas2bitbake-setup.py)
- Runs kas dump offline per kas/machine/*.yml and maps the flattened result into bitbake-setup templates.
- meta-avocado itself (the url-less local repo in kas) is emitted as bb-layers-file-relative pointing at the live working tree
Generated configs (27 machines)
- One avocado-.conf.json per machine plus the matching meta-avocado/conf/fragments/avocado-build/.conf.
- Vendor sources pinned to the same wrynose/wrynose-avocado revisions as kas.
- Covers the full machine set.
Wrapper (scripts/bitbake-setup)
- Pins the build top dir under meta-avocado/bitbake-builds/ (mirrors kas's keep-build-trees-in-checkout convention).
- Caches DL_DIR/SSTATE_DIR in a shared external cache (default ~/.cache/avocado-bitbake-setup), overridable via AVOCADO_BB_CACHE / AVOCADO_DL_DIR / AVOCADO_SSTATE_DIR, so a rm -rf bitbake-builds no longer nukes downloads/sstate.
- .gitignores the bootstrap bitbake clone and the build trees.
Docs
- Both setup paths documented in the top-level README, plus bitbake-setup/README.md
Kernel fix
Kernel: (which should probably be on it's own PR, but I stashed it here)
- # CONFIG_USB_SERIAL_CONSOLE is not set in the qemu and x86-64 kernel fragments. The common-pc BSP sets it =y, which hard-depends on USB_SERIAL=y. AvocadoOS ships USB_SERIAL=m, so it silently dropped and tripped do_kernel_configcheck.