linux/poky.git/scripts/oe-setup-layers, branch master

The poky repository master branch is no longer being updated.

2025-11-07T13:31:53+00:00

You can either: a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs b) use the new bitbake-setup You can find information about either approach in our documentation: https://docs.yoctoproject.org/ Note that "poky" the distro setting is still available in meta-yocto as before and we continue to use and maintain that. Long live Poky! Some further information on the background of this change can be found in: https://lists.openembedded.org/g/openembedded-architecture/message/2179 Signed-off-by: Richard Purdie

oe-setup-layers: make "path" optional

2025-11-03T17:40:41+00:00

Layer names and path are often redundant. Allow users to omit the path key when it is equal to the layer name by using the layer name as a default value for its path. For example, from layers.example.json: "sources": { "meta-alex": { "path": "meta-alex" }, "meta-intel": { "path": "meta-intel" }, "poky": { "path": "poky" } }, Update the schema to stop requiring "path" and remove it in example for "meta-intel". (From OE-Core rev: 7f36f0526fae5a81f9bc02e16cc849a2b1ea5797) Signed-off-by: Yoann Congal Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

oe-setup-build: add a tool for discovering config templates and setting up builds

2024-02-19T11:47:53+00:00

This is another piece of the puzzle in setting up builds from nothing without having to write custom scripts or use external tools. After layers have been fetched and placed into their respective locations by oe-setup-layers, one would surely want to proceed to the actual build, and here's how: 1. Without arguments the tool reads available layers from .oe-layers.json file (written out by oe-setup-layers or a fallback under scripts/), prints what templates it has found, and asks the user to select one, as seen below. This will land the user in a shell ready to run bitbake: ============================================= alex@Zen2:/srv/work/alex$ ./setup-build Available build configurations: 1. alex-configuration-gadget This configuration will set up a build for the purposes of supporting gadget. 2. alex-configuration-gizmo This configuration allows building a gizmo. 3. poky-default This is the default build configuration for the Poky reference distribution. Re-run with 'list -v' to see additional information. Please choose a configuration by its number: 1 Running: TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/configuration-gadget . /srv/work/alex/poky/oe-init-build-env /srv/work/alex/build-alex-configuration-gadget && /bin/bash You had no conf/local.conf file. This configuration file has therefore been created for you from /srv/work/alex/meta-alex/conf/templates/configuration-gadget/local.conf.sample You may wish to edit it to, for example, select a different MACHINE (target hardware). You had no conf/bblayers.conf file. This configuration file has therefore been created for you from /srv/work/alex/meta-alex/conf/templates/configuration-gadget/bblayers.conf.sample To add additional metadata layers into your configuration please add entries to conf/bblayers.conf. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: https://docs.yoctoproject.org For more information about OpenEmbedded see the website: https://www.openembedded.org/ This configuration will set up a build for the purposes of supporting gadget. Please refer to meta-alex/README for additional details and available bitbake targets. ============================================== 2. It is also possible to list available configurations without selecting one using 'setup-build list' or to select and setup one non-interactively with 'setup-build setup'. 3. The full set of command line options is: $ ./setup-build --help usage: setup-build [-h] [--layerlist LAYERLIST] {list,setup} ... A script that discovers available build configurations and sets up a build environment based on one of them. Run without arguments to choose one interactively. positional arguments: {list,setup} list List available configurations setup Set up a build environment and open a shell session with it, ready to run builds. optional arguments: -h, --help show this help message and exit --layerlist LAYERLIST Where to look for available layers (as written out by setup-layers script) (default is /srv/work/alex/.oe-layers.json). $ ./setup-build list --help usage: setup-build list [-h] [-v] optional arguments: -h, --help show this help message and exit -v Print detailed information and usage notes for each available build configuration. $ ./setup-build setup --help usage: setup-build setup [-h] [-c configuration_name] [-b build_path] [--no-shell] optional arguments: -h, --help show this help message and exit -c configuration_name Use a build configuration configuration_name to set up a build environment (run this script with 'list' to see what is available) -b build_path Set up a build directory in build_path (run this script with 'list -v' to see where it would be by default) --no-shell Create a build directory but do not start a shell session with the build environment from it. 4. There's an an added hint in oe-setup-layers about how to proceed (as it is really not user-friendly to fetch the layer repos successfully and then exit without a word), and a symlink to the script from the top level layer checkout directory. 5. The selftest to check layer setup has been adjusted to run a basic check for template discovery and build setup. The revision of poky to be cloned has been bumped to 4.1, as that's the first version with a default template in a standard location. (From OE-Core rev: 1360b64e88cda7dddfb0eca6a64f70c13dafb890) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

scripts/oe-setup-layers: write a list of layer paths into the checkout's top dir

2024-02-19T11:39:08+00:00

This is beneficial for setting up builds, as this list can be used to determine reliably where the actual layers are, and discover available configurations from them. Also adjust the selftest to check the presence of that file rather than any specific layer in a hardcoded location. Sample output (paths are written relative to the file for relocatability and ease of reading): { "layers": [ "meta-openembedded/meta-filesystems", "meta-openembedded/meta-gnome", "meta-openembedded/meta-initramfs", "meta-openembedded/meta-multimedia", "meta-openembedded/meta-networking", "meta-openembedded/meta-oe", "meta-openembedded/meta-perl", "meta-openembedded/meta-python", "meta-openembedded/meta-webserver", "meta-openembedded/meta-xfce", "poky/bitbake/lib/layerindexlib/tests/testdata/layer1", "poky/bitbake/lib/layerindexlib/tests/testdata/layer2", "poky/bitbake/lib/layerindexlib/tests/testdata/layer3", "poky/bitbake/lib/layerindexlib/tests/testdata/layer4", "poky/meta-poky", "poky/meta-selftest", "poky/meta-skeleton", "poky/meta-yocto-bsp", "poky/meta" ], "version": "1.0" } (From OE-Core rev: 82743f4f767f8016564be0d9d6c0d8fe9e067740) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

scripts/oe-setup-layers: Update how to determine if directory is git repo

2023-10-06T10:51:11+00:00

Previously _is_repo_git_repo() would return a result containing b'true\n' or b'false\n' if 'git rev-parse' ran successfully, instead of True of False. While this can be solved using e.g. result.strip().decode("utf-8") == "true", there are some other cases to consider. First, .git can be a file and not a directory when using a worktree. Second, an emtpy .git directory in 'repodir' for which some parent of 'repodir' is an actual git repo will still return True in this case. To account for these cases as well, use 'git rev-parse --show-toplevel' and compare the result against 'repodir' instead of using 'git rev-parse --is-inside-git-dir'. (From OE-Core rev: 0830f53900dd7fd669a7d6492325559ad3225302) Signed-off-by: Jermain Horsman Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

scripts/oe-setup-layers: do not clobber json module with a variable named 'json'

2023-02-20T15:18:30+00:00

(From OE-Core rev: 91e5aef9fd710b08ead9491f1900fbab5386b157) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

scripts/oe-setup-layers: correct variable names - layers should be called repos

2023-02-20T15:18:30+00:00

The script is operating on layer repositories, which can and do sometimes contain several layers. This distinction is important as the script will be tweaked to write a record of actual layer locations. (From OE-Core rev: 833965e6001db98039c0aa816ae661232213bcea) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

scripts/oe-setup-layers: print a note about submodules if present

2023-02-15T10:21:34+00:00

(From OE-Core rev: 7f16c1c0229110c242f2e064d612d0d35823bf8d) Signed-off-by: Alexander Kanavin Signed-off-by: Luca Ceresoli Signed-off-by: Richard Purdie

scripts/oe-setup-layers: Make efficiently idempotent

2023-01-18T16:42:28+00:00

The effect of subsequent setup-layers executions is now either a NOOP or the minimal set of changes required to ensure layers precisely match the JSON configuration. This change allows setup-layers to be incorporated into a team's configuration management strategy. In particular, the configuration JSON manages a "pinning policy" that documents the oversight of sources of change (a requirement for embedded development in highly regulated industries). One model for this strategy would work as follows. Team level policy is developed to regularly review upstream commits that occur between the current upstream HEAD and the previously pinned revision. The JSON configuration is periodically updated after a review, test, and approval process. In the rare instance that an upstream change is considered problematic, the bbappend mechanism can be used to make relevant changes in the team's project repository. This approach also requires that team developers regularly run the project repository copy of setup-layers. This is most easily accomplished by including setup-layers in a wrapper script that all team developers use to interact with the bitbake tool suite (e.g. "bb bitbake foo-image"). Project level policy and oversight is effectively "contained" within this wrapper script, thereby reducing a significant source of human error. Left unstated, but acknowledged here, are a number of nuances required to successfully implement the above strategy. The details are out of scope for this explanation. What should be clear is that a larger configuration management strategy can now benefit from the utility provided by setup-layers. Note: Neither the above configuration management strategy example nor the change itself is intended to alter the original intent to use "bitbake-layers create-layers-setup destdir" to keep pace with upstream activity for those who wish to use it that way. (From OE-Core rev: da2e01cacd98715318a5307fe0618dbca0cf1fe7) Signed-off-by: Chuck Wolber Signed-off-by: Luca Ceresoli Signed-off-by: Richard Purdie

meta/files/layers.schema.json: drop the layers property

2022-09-02T14:58:26+00:00

This is a leftover from one of the RFC iterations, where the property contained available machines, distros and templates. As all of those were dropped from the final version, there is no reason to list the layers either anymore. Normally this would be a backwards incompatible change, but as the layer setup itself was just merged, I think we can do a quick fixup :-) (From OE-Core rev: 64a774de0e154ef81f20853fec903b17d9985a72) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie