On Thu, 2018-02-22 at 07:53 +0100, Jonas Bonn wrote: > 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.
refkit used the same approach. One thing that I would prefer to do differently is the location of the submodule: having them in their own directory would make it more transparent which code is "external" and which is "internal". > "env" is a script containing just the following: > . ./oe-core/oe-init-build-env build/ bitbake/ We ended up with a top-level "oe-init-build-env" wrapper script around the actual oe-core/oe-init-build-env. That way the repo could be used the same way as poky. The script sets TEMPLATECONF, so the usual local build setup happens based on refkit sample files. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel