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 <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <abongwabonalais@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enclose expansions of BUILDDIR in quotes in order to correctly handle paths
which include spaces.
(From OE-Core rev: 0c08723cf5ebc1a7df7dc4ca36cffa090286468c)
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This script is only useful when sourced into a shell.
These changes improve the detection of this operation,
no matter how the script is referenced.
(From OE-Core rev: cac863e958a0c8fe0f8a84dc194273c699f0c40f)
Signed-off-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the bitbake --status-only and the fact that bitbake.lock will
contain the host name and port to determine when to activate or
shutdown the stay resident bitbake server.
This allows a end developer to cleanly switch between the two ways to
use bitbake as well as enter the memres bitbake server from multiple
shells without starting the server if it is already running.
(From OE-Core rev: d71059c86a8160f39af6ddfdd30c86835f4eb959)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If BBSERVER is set, we should unset it before proceeding. Its assumed the
user will have unloaded the server from memory should they have wished
to do so.
(From OE-Core rev: 5cc4d315709de195bfb0655c2f00ae2267bfa4c6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Typoes fixed: "enviroment", "editted", "spliting", "scheulder".
(From OE-Core rev: 17e981a857a51b0bec08c929e8539d36d83874b6)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #671]
"readlink -f" in Ubuntu 10.04 is buggy: it doesn't ignore a trailing / (e.g.,
"readlink -f /tmp/non-existent-dir/" returns nothing, but according to
http://www.gnu.org/s/coreutils/manual/coreutils.pdf it should do that --
hence we get bug 671. It seems Ubuntu 10.10 or even later Ubuntu 11.04,
and other Linux distributions(e.g., Open Suse 11.4) haven't such an issue.
So I think we should detect this and ask Ubuntu 10.04 users to avoid supply
a path with trailing slash here.
Moreever, I also add the detection of non-existent path, e.g.,
source oe-init-build-env /non-existent-dir/build
can be detected and we'll print an error msg.
And, if we get errors in oe-buildenv-internal, we should stop the script
and shouldn't further run.
(From OE-Core rev: 651ccb3b031d9ccb8331505a51171372002230d9)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
