> Am 21.05.2018 um 21:04 schrieb Alexander Kanavin > <alexander.kana...@linux.intel.com>: > > On 05/21/2018 06:55 PM, Jens Rehsack wrote: >> Move scripts/bashrc from meta-jens/scripts to oe-core to share user-friendly >> oe builddir management with community. Using this script will help manage >> multiple BSPs and targets like perl developers using perlbrew. > > Please explain in detail what this does, and why is it superior to existing > tools. What are the typical usage scenarios? Where and how this should be > documented and tested? It is not a good idea to just add something into > scripts/, as no one will know or use it, and so it will just quietly bitrot.
Yes, the commit message is a bit ... weird.
Anyway - what it does should not be part of the commit message in detail, but
maybe the help and the tool itself should be a bit reworked for being
up-to-date.
However - let's prove the interest first, fixing the stuff a little bit later
(I reserved the upcoming long weekend for Open-Source...)
When I log into my build machine, I just do
$ oe_builddir use ~/gpw-community-bsp/gpw-yocto-platform/
and I'm in the right location and have all environment settings prepared to
start a bitbake immediately.
$ oe_builddir help
oe_builddir <command> [argument]
Available commands:
use use specified build-dir, setup when local.conf and/or
bblayers.conf are missing
setup create default builddir
avail list possible build-dir's
layers list layers used in BSP
repos list repositories used in BSP
prune prune old builds
off remove all settings from oe from shell environment
Tells you, what could be expected (very short).
It's all plain shell - so everyone can adopt it easily to local requirements.
Further, it supports setting flags and tools within ''oe_builddir use''.
When you have a look at my layers I use for
https://www.slideshare.net/JensRehsack/perl-onembeddeddevices - I need a
special bitbake wrapper to build root and recoveryfs, and I have and additional
environment variable I need to inject into recipes through bitbake.
$ cat ../sources/meta-jens/.oe-init
__oe_prepend_path "$(readlink -f $OEROOT/..)/meta-jens/scripts"
__oe_append_extrawhite "VLAN_GRP"
$ cat ../sources/meta-gpw/.oe-init
__oe_append_extrawhite "WANTED_ROOT_DEV"
When I set up the workshop environment after 2 years of abstinence - I realized
that there are some cool improvements available, like updating all repos from
upstream and some of the utility routines can be simplified. But this effort
isn't sanely spent when the entire idea of a https://perlbrew.pl
look-and-feel-alike is rejected.
>> +__oe_check_py () {
>> + # Make sure we're not using python v3.x. This check can't go into
>> + # sanity.bbclass because bitbake's source code doesn't even pass
>> + # parsing stage when used with python v3, so we catch it here so we
>> + # can offer a meaningful error message.
>> + py_v3_check=`/usr/bin/env python --version 2>&1 | grep "Python 3"`
>> + if [ "$py_v3_check" != "" ]; then
>> + echo >&2 "Bitbake is not compatible with python v3"
>> + echo >&2 "Please set up python v2 as your default python
>> interpreter"
>> + return 1
>> + fi
>
> Bitbake has in fact been compatible with Python 3.x for several releases. The
> above check is not particularly useful, as /usr/bin/python nearly always
> points to a 2.x version.
True, with many other details. I will happily fix this and all other quirks
once we agree on above ;)
Cheers
--
Jens Rehsack - rehs...@gmail.com
signature.asc
Description: Message signed with OpenPGP
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
