summaryrefslogtreecommitdiffstats
path: root/oe-init-build-env-memres
Commit message (Collapse)AuthorAgeFilesLines
* oe-init-build-env*: Make them actually return failuresPeter Kjellerstedt2016-03-201-3/+7
| | | | | | | | | | | | 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>
* oe-init-build-env*: Remove unnecessary differences between the scriptsPeter Kjellerstedt2016-03-201-15/+15
| | | | | | | | | | | | | 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>
* oe-init-build-env*: Update/correct comment about specifying argumentsPeter Kjellerstedt2016-03-201-4/+4
| | | | | | | | (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>
* oe-init-build-env*: Allow $OEROOT to be predefinedPeter Kjellerstedt2016-03-201-7/+9
| | | | | | | | | | | | | | | | | | 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>
* oe-init-build-env-memres: Fix source checkEsquivel, Benjamin2015-03-201-20/+25
| | | | | | | | | | | | | | | 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>
* oe-init-build-env-memres: Fix automatic port usageRichard Purdie2014-09-231-4/+4
| | | | | | | | | | | | | 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>
* oe-init-build-env-memres: Add auto port functionalityJason Wessel2013-12-021-11/+16
| | | | | | | | | | | | | 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>
* oe-init-build-env: Allow startup with and without memresJason Wessel2013-12-021-3/+18
| | | | | | | | | | | | | | | 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>
* oe-init-build-env-memres: Unset BBSERVER if already setRichard Purdie2013-10-071-0/+4
| | | | | | | | | 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>
* oe-init-build-env-memres: use shell instead of Python to show the port numberRoss Burton2013-09-261-1/+1
| | | | | | | (From OE-Core rev: 024e95696bad8f2ff09e1fda28c96d89d10999a1) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add memory resident bitbake scriptRichard Purdie2013-08-261-0/+55
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>