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.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This script expected the port number to be specified first, which is
somewhat counter-intuitive especially if you're used to
oe-init-build-env; besides, in local usage you are unlikely to need to
specify a custom port. Given that few people are using this yet (based
on the issues I have recently fixed), switch the arguments around so
that the two scripts behave consistently.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

While at it, also fix:
* consistent indentation (four spaces)
* unset temporary variables
* use $(...) instead of `...`

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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]

Signed-off-by: Benjamin Esquivel <benjamin.esquivel@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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]

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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.

Signed-off-by: Jason Wessel <jason.wessel@windriver.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.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>