On 21 February 2018 at 15:09, Martin Hundebøll <m...@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 -- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel