linux/poky.git/oe-init-build-env, branch 5.2_M1

oe-init-build-env: generate .vscode from template

2024-02-19T11:34:33+00:00

Provide a reasonable default configuration for VSCode and the yocto.bitbake extension. The generated default configuration is generic and minimal. It's mostly supposed to prevent VSCode from OOM exceptions if the build directory is in the scope of the indexer plugins of VSCode. But it also configures the yocto-bitbake plugin to just work without manual user interaction. The configuration is only generated if VSCode is installed. Currently, VSCode is one of many popular editors for Yocto/OE. Removing the check would mean that the configuration would be generated by e.g. oe-selftest or for users not using VSCode. If it should prove useful, the check can be removed later. Customization for other layers is possible. A layer might provide it's own oe-setup-build-env script which calls the oe-setup-vscode script from poky with different folders. But it's also possible to override the oe-setup-vscode script by another layer with a custom implementation. (From OE-Core rev: 48829be7ab2edcbc2e4473f81cdaf35889d63f9c) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

oe-init-build-env: add quotes around variables to prevent word splitting

2022-04-05T21:23:40+00:00

Used shellcheck to add quotes to the variables. This is to make sure that directories with names that have space between, such as "Desktop/projects/test repo/poky" will not be considered as 2 separate words. With this modification, running the command "source oe-init-build-env" will not give the error "bash: oe-init-build-env: No such file or directory" (From OE-Core rev: b07a70fbf78f2beba639580e37dffbc0a73bc99f) Signed-off-by: Abongwa Bonalais Amahnui Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

meta/lib+scripts: Convert to SPDX license headers

2019-05-09T15:31:55+00:00

This adds SPDX license headers in place of the wide assortment of things currently in our script headers. We default to GPL-2.0-only except for the oeqa code where it was clearly submitted and marked as MIT on the most part or some scripts which had the "or later" GPL versioning. The patch also drops other obsolete bits of file headers where they were encoountered such as editor modelines, obsolete maintainer information or the phrase "All rights reserved" which is now obsolete and not required in copyright headers (in this case its actually confusing for licensing as all rights were not reserved). More work is needed for OE-Core but this takes care of the bulk of the scripts and meta/lib directories. The top level LICENSE files are tweaked to match the new structure and the SPDX naming. (From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e) Signed-off-by: Richard Purdie

oe-init-build-env: Error out when failed to locate cwd

2019-03-12T18:57:41+00:00

Ubuntu's /bin/sh symlinks to /bin/dash by default, so subprocess.check_call(oe-init-build-env, cwd=builddir) would be failed since pwd is builddir, and there is no $builddir/oe-init-build-env, this would lead to other confusing errors, check and error it out earlier to make it easier to locate the problem. We don't meet the problem when manually run ". oe-init-build-env" is because Ubuntu's default login shell is bash, but subprocess.check_call() doesn't respect to login shell, so the error only happens in situations like subprocess.check_call(). And also print errors to stderr as oe-buildenv-internal does. (From OE-Core rev: 632c54b7686e60ee320ed1a7ac7d889790599d27) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

oe-init-build-env-memres: Drop it

2017-07-21T07:44:25+00:00

With the new server structure we no longer need this separate environment init script. Just set BB_SERVER_TIMEOUT to be greater than zero and bitbake will remain in memory and the UI will auto-reconnect to it. Also clean out the old shutdown code from oe-init-build-env which also doesn't make sense now. (From OE-Core rev: a17724d687f9c04dc21f2f369da2b492f7119ba0) Signed-off-by: Richard Purdie

oe-init-build-env*: Make them actually return failures

2016-03-20T23:12:30+00:00

If either of the internal scripts (oe-buildenv-internal and oe-setup-builddir) failed, oe-init-build-env (and oe-init-build-env-memres) would still return success. (From OE-Core rev: 40764c7039f1ee161916d4fbf7dfe15fb964030e) Signed-off-by: Peter Kjellerstedt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

oe-init-build-env*: Remove unnecessary differences between the scripts

2016-03-20T23:12:30+00:00

While at it, also fix: * consistent indentation (four spaces) * unset temporary variables * use $(...) instead of `...` (From OE-Core rev: 1295d413f27941d0763a3d58982378738bf3ca06) Signed-off-by: Peter Kjellerstedt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

oe-init-build-env*: Update/correct comment about specifying arguments

2016-03-20T23:12:30+00:00

(From OE-Core rev: 9c7e3cfcff08bd47b0c1eeb63d8055d8a8b12935) Signed-off-by: Peter Kjellerstedt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

oe-init-build-env*: Allow $OEROOT to be predefined

2016-03-20T23:12:30+00:00

The current implementation of oe-init-build-env and oe-init-build-env-memres requires that they are sourced from the directory that will be known as $OEROOT. This makes it hard to write a wrapper script with the same name as the original OE script which, e.g., sources the original OE script from a sub-directory. With this change, $OEROOT can be predefined when oe-init-build-env or oe-init-build-env-memres is sourced, allowing the original OE scripts to be anywhere. (From OE-Core rev: 3327e2a9222004d8ac7974cb1d9fe77c81176cfc) Signed-off-by: Peter Kjellerstedt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

scripts: hand the TEMPLATECONF local over to setup-builddir

2015-12-28T09:25:19+00:00

(From OE-Core rev: 0bf9d919bba5780d34cc6ac9dde2c74bb07b8342) Signed-off-by: Marcus Müller Signed-off-by: Ross Burton Signed-off-by: Richard Purdie