[oe] Splitting meta-oe?

[Jonas Bonn]

On 21 February 2018 at 15:09, Martin Hundebøll <mnhu at prevas.dk> wrote:

> Now that the discussion branched out a bit...
>
> We would like better support for this too. Our setup uses a "manifest"
> repository with git submodules to setup the layers:
>
> > yocto/
> >       meta-poky/
> >       meta-qt5/
> >       meta-foo/
> >       meta-bar/
> >       conf/
> >            bblayers.conf
> >            local.conf
> >       .gitmodules
>
> With this setup, customers simply need to clone our yocto repo
> recursively, run `yocto/meta-poky/oe-init-build-env yocto` and then
> `bitbake image-recipe`.
>
> But this is rather inflexible, as it requires the "yocto" folder to be the
> build folder to activate the config files...
>
> We looked into putting the configs in "meta-foo/conf/*.conf.sample" and
> using TEMPLATECONF, but the "oe-init-build-env" script is rather picky
> about poky being the "top" directory.
>
> I guess the oe-init-build-env script can be changed to look for
> .templateconf in any parent folder?


Putting together a deliverable setup that's easy for the customer to get
started with is a bit tricky.  Here's the approach that's worked well for
me:

/myproject
    /env        <-- script
    /build
    /meta-myproject
    /bitbake
    /oe-core
    /meta-layer1
    /meta-layer2

env, build, meta-myproject are part of the myproject repo, everything else
is a submodule.

"env" is a script containing just the following:
. ./oe-core/oe-init-build-env build/ bitbake/

meta-myproject is the "local layer" that contains project specific recipes
and appends.

The build directory contains:
build/conf/bblayers.conf.sample
build/conf/conf-notes.txt
build/conf/local.conf.sample
build/conf/templateconf.cfg

The interesting parts here are:
bblayers.conf.sample contains something like this:
BBLAYERS ?= " \
  ##OEROOT##/meta \
  ##OEROOT##/../meta-layer1 \
  ##OEROOT##/../meta-layer2 \
  ##OEROOT##/../meta-myproject \
  "

and templateconf.cfg contains this magic:
../build/conf

With this setup, the customer does:
git clone ..../myproject.git
git submodule --update init
./env
bitbake customer-image

The 'env' command nicely prints the contents of conf-notes which reminds
the customer of the names of the images (customer-image,
customer-dev-image, customer-special-image, etc) that are avaiable to be
built so that they don't need to search the repo for the image recipes
because they can't remember what they were called.

The only additional tweak that I recommand be made manually beyond the
above is to point build/sstate-cache to somewhere outside of the cloned
repo.  That way, the entire repo can be deleted, re-cloned, and quickly
rebuilt when people get themselves lost in the labyrinth...

Advantages of the above:
i)  oe-core is just another layer and therefore just another submodule...
no changes are made to it locally
ii)  git log on the myproject repo ties submodule updates and modifications
to the "local layer" together so it's clear why recipes were changed
iii)  since meta-mylayer is not an external layer/repo, I'm working in only
one git repo when doing updates (assuming the submodules aren't changing)

Anyway, just wanted to share that, in case it's useful for someone.

/Jonas