Commit Graph

11 Commits

Author SHA1 Message Date
Peter Kjellerstedt dd5f2f7275 oe-init-build-env*: Make them actually return failures
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>
2016-03-20 23:12:30 +00:00
Peter Kjellerstedt ea28de6d39 oe-init-build-env*: Remove unnecessary differences between the scripts
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>
2016-03-20 23:12:30 +00:00
Peter Kjellerstedt 51aa00f0f8 oe-init-build-env*: Update/correct comment about specifying arguments
(From OE-Core rev: 9c7e3cfcff08bd47b0c1eeb63d8055d8a8b12935)

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>
2016-03-20 23:12:30 +00:00
Peter Kjellerstedt 16fb9b80e3 oe-init-build-env*: Allow $OEROOT to be predefined
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>
2016-03-20 23:12:30 +00:00
Esquivel, Benjamin 61e14ad4eb oe-init-build-env-memres: Fix source check
The source check was referring to oe-init-build-env instead of the
memres. It could be executed without the proper failure message and the
corresponding exit command out of the script. This commit makes the
memres script look more like the oe-init-build-env with the correct
script name.

[YOCTO #7487]

(From OE-Core rev: 1666b41e73f2aa7bd736c3e9bf3797946bff61b5)

Signed-off-by: Benjamin Esquivel <benjamin.esquivel@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-03-20 10:56:03 +00:00
Richard Purdie 177af6e831 oe-init-build-env-memres: Fix automatic port usage
The use of an automatic port wasn't working correctly since the server
was never getting started when port == -1. This fixes things so the
server is started when port is not specified (i.e. automatic) ensuring
this happens before BBSERVER is set.

[YOCTO #6563]

(From OE-Core rev: 982553b6d56ca4bfd095c1bcb736ae3b77deefa7)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-23 20:06:06 +01:00
Jason Wessel 72e650d97c oe-init-build-env-memres: Add auto port functionality
In order to run multiple bitbake memory resident servers on the same
machine they must each use different ports.

This patch works in conjuction with bitbake to make the auto port
selection and lazy server startup the default.

(From OE-Core rev: 9cf1ac73c4e35101a4f5c01a5e1c53f9d567bc58)

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-12-02 11:28:27 +00:00
Jason Wessel 644a1a27ec oe-init-build-env: Allow startup with and without memres
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>
2013-12-02 11:28:27 +00:00
Richard Purdie acf547084a oe-init-build-env-memres: Unset BBSERVER if already set
When starting a new server we don't want bitbake to connect to an existing
server so ensure BBSERVER is unset.

(From OE-Core rev: f54bb9e7897e6e68acb7b4f88d998fdb149a7e47)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-10-07 09:37:31 +01:00
Ross Burton 1bff3fc86f oe-init-build-env-memres: use shell instead of Python to show the port number
(From OE-Core rev: 024e95696bad8f2ff09e1fda28c96d89d10999a1)

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-26 17:15:32 +01:00
Richard Purdie 5f2170bd4a Add memory resident bitbake script
This adds an init script which instead of the standard bitbake, launches
a memory resident bitbake, defaulting to port 12345. It expects a port
number to use as the first option.

Right now this is experimental but I think its probably worth wrapping
up in a form people can more easily experiment with it. There are some
known issues:

a) It throws some debug output due to the lack of a UI which we need
   to clean up
b) It should probably be able to auto select a free port
c) You get a nice backtrace if you specify a build directory but
   not a port number

I'd also highlight there are security issues here if you don't trust
users who can connect into localhost. We might need to look at named
pipes or something similar for something limited to the current user.

(From OE-Core rev: 52c7f8bba86a43b89f24a23d545c99d75b67555f)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-08-26 11:29:44 +01:00