[OE-core] [PATCH] scripts/oe-init-bashrc: add more user-friendly oe-setup utility

Jens Rehsack rehsack at gmail.com
Mon May 28 18:41:11 UTC 2018



> Am 21.05.2018 um 21:04 schrieb Alexander Kanavin <alexander.kanavin at 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 - rehsack at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180528/5ecb45b6/attachment-0002.sig>


More information about the Openembedded-core mailing list