On Thu, 2017-05-25 at 16:04 +0000, Koehler, Yannick (HPN Aruba) wrote: > This is my opinion, I think we could alter bitbake to retrieve the SRC_URI > and S information from the bblayers.conf (instead of having recipes like for > package). > > sample > # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf > # changes incompatibly > LCONF_VERSION = "6" > > BBPATH = "${TOPDIR}" > BBFILES ?= "" > > BBLAYERS ?= " \ > ##OEROOT##/meta \ > ##OEROOT##/meta-yocto \ > ##OEROOT##/meta-yocto-bsp \ > > ##OEROOT##/meta-openembedded;SRC_URI="git://g...@github.com/openembedded/meta-openembedded;protocol=ssh;branch=master";SRCREV="${AUTOREV}" > \ > " > BBLAYERS_NON_REMOVABLE ?= " \ > ##OEROOT##/meta \ > ##OEROOT##/meta-yocto \ > " > > Bitbake could then fetch/update the layer from the SRC_URI into the location > given "##OEROOT##/meta-openembedded" prior to parsing.
Richard has indeed been thinking about a solution like that for 2.4. I agree that it looks attractive at first glance. However, I see a chicken-and-egg problem with no (easy?) solution: a developer who wants to get started with a distro "foo" first needs to check out the repo containing that distro's definition and local.conf.sample, then somehow also check out a version of bitbake that works with that distro revision, and only then can bitbake download the additional layers. Perhaps we can make it so that bitbake has a separate tool that works outside of a build environment and then sets up that environment. -- 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. -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto