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>
> > 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
> started with is a bit tricky. Here's the approach that's worked well
> /env <-- script
> 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