linux/poky.git/meta/conf/layer.conf, branch yocto-2.7

layer.conf: Update to warrior release name series

2019-04-02T14:24:11+00:00

(From OE-Core rev: 13e45fffb66c7cb7ba0d07bed063c0c5ce57004b) Signed-off-by: Richard Purdie

ccache.bbclass: Refactor it to make it more reliable

2019-01-14T11:35:55+00:00

The previous ccache.bbclass has the following problems: - It uses host's ccache for native recipes, but this may not work on some hosts, for example, it nerver works on my Ubuntu 14.04.4, there are always build failures (m4-native failed at do_configure, and others will also be failed if I disable CCACHE for m4-native) - native/nativesdk/cross/crosssdk recipes use host's ccache, but target uses ccache-native, this may confuse user. - The target recipes may use both host's ccache and ccache-native, this may cause unexpected problems and be hard to debug. This is because ccache-native is in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS, so ccache-native may not be present when rebuild target recipes, and then it would use hosttools/ccache, but the previous ccache files were generated by ccache-native. - Target recipes can't use ccache when no ccache is installed on the host: CCACHE = "${@bb.utils.which(d.getVar('PATH'), 'ccache') and 'ccache '}" After refactored: All types recipes (native, target and others) will use ccache-native except ccache-native itself, host's cache won't be used any more. It is more reliable now, which will work everywhere when ccache-native can be built. And now we need use "CCACHE_DISABLE = '1'" to disable ccache for the recipe rather than "CCACHE = ''" since we set CCACHE in anonymous function, and d.getVar('CCACHE') works after "CCACHE ??=" which is set in bitbake.conf, so we can't check whether CCACHE is set or not in anonymous function since it is always set. Use CCACHE_DISABLE to disable it would be more clear. (From OE-Core rev: b25271b65262f70d849a4861da216c9be6c54d53) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

recipes: Drop virtual/libc-for-gcc

2018-12-26T11:19:54+00:00

We no longer have special "libc" for gcc so we can rely on plain virtual/libc and reduce the complexity in the dependencies. (From OE-Core rev: 122217b421f749b5fef52bea44ad6e04bc8f8d3a) Signed-off-by: Richard Purdie

weston: Split out machine specific configuration

2018-10-28T08:31:57+00:00

Weston needs to be configured to load the fbdev driver when run on a QEMU system. Other MACHINEs may want to also provider their own configuration as well.. Adding a new RRECOMMEND configuration package will allow this, but avoid installing empty packages/files in the majority case where it is not needed. Add maintainer entry as well. (From OE-Core rev: 0f43ea8510ae6148a49eb25accac407b6b301b43) Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie

systemd: Remove items that made this machine (qemu) specific

2018-10-21T20:30:35+00:00

Create a new systemd-conf recipe to contain the specific system/machine configuration items. This new package is now machine specific. Without doing this trying to create a single system with multiple BSPs, one of which was qemu based, would result in the systemd -and- everything that dependend upon systemd to have their hash changed. The hash changing means lots of rebuilds, but worse if it's a package based system each different machine ends with a new PR value and a newly generated package. (From OE-Core rev: d3395418758ed414eee3e95e13d2d8bc5dca88cc) Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie

layer.conf: Drop sumo from LAYERSERIES_CORENAMES

2018-10-01T12:04:49+00:00

Prepare for release and drop sumo for the compatible list of layer names. This will mean other layers need updating to continue to indicate compatibility with master but that is intentional at this part of the release cycle, we want layers to indicate compatibility and show they're up to date. (From OE-Core rev: 9ec5a8a0f86510f7aae572dfb79e8bda73d4e0fc) Signed-off-by: Richard Purdie

layer.conf: Add thud to LAYERSERIES_CORENAMES

2018-09-24T11:30:16+00:00

With the release approaching, add thud to LAYERSERIES_CORENAMES and update oe-core to use this release series. "sumo" will be removed during M4 in the next couple of weeks so people need to start updating their master layers in preperation for release. (From OE-Core rev: 986792481fa005fe136fd4b4e388042492b1ad8a) Signed-off-by: Richard Purdie

sstate: Avoid indirect autoconf-archive-native dependencies

2018-08-21T13:49:42+00:00

remove the indirect dependcy of autoconf-archive-native via SSTATE_EXCLUDEDEPS_SYSROOT to avoid not needed .m4 installed into sysroot, which may cause compile problem. (From OE-Core rev: d23156460e2b8f6684bd3005d7fa09b2c73e522e) Signed-off-by: Changqing Li Signed-off-by: Richard Purdie

sstate: Avoid indirect bison-native dependencies (via SSTATE_EXCLUDEDEPS_SYSROOT)

2018-08-16T21:40:27+00:00

Avoid adding bison-native to the sysroot without a specific dependency in the recipe. This means indirect dependencies (e.g. X -> Y -> binutils-cross -> bison-native) no longer meet the dependency incidentally. This improves determinism and avoids build failures when people switch to external toolchains. Based on an idea by Richard Purdie: http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146324.html (From OE-Core rev: b7edc20cc2dd82989bd9561f860cb25478a40f69) Signed-off-by: André Draszik Signed-off-by: Richard Purdie

sstate: use SSTATE_EXCLUDEDEPS_SYSROOT for skipping base-passwd|shadow-sysroot recipes

2018-08-16T08:49:39+00:00

Use the newly introduced SSTATE_EXCLUDEDEPS_SYSROOT for specifying the base-passwd|shadow-sysroot recipes to be excluded from a recipe sysroot. (From OE-Core rev: 68e502e9063a88532fe0154f152ba408f0091900) Signed-off-by: André Draszik Signed-off-by: Richard Purdie