| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You can either:
a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs
b) use the new bitbake-setup
You can find information about either approach in our documentation:
https://docs.yoctoproject.org/
Note that "poky" the distro setting is still available in meta-yocto as
before and we continue to use and maintain that.
Long live Poky!
Some further information on the background of this change can be found
in: https://lists.openembedded.org/g/openembedded-architecture/message/2179
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, class extensions are implmented using shadow variables and
access indirection which is horribly ineffient and ugly.
Switch to using the new bitbake filter API, which allows a translation
of the variable before the expanded value is returned. This allows us
to drop the shadow variable accesses. It also avoids the need to iterate
PACKAGES and make many variable changes since a filter against RDEPENDS
applies to RDEPENDS:${PN} and all of it's other overridden values.
Since data expansion happens at access, it also avoids many of the race
conditions this code has tranditionally been plagued with.
(From OE-Core rev: 24a9858a8927e91d499ee342ed93a0dbb44d83bc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want nativesdk packages to depend on correct recipes introduced
by PACKAGE_WRITE_DEPS, so do the same mapping just as we do for DEPENDS.
Before this change:
nativesdk-glib-2.0 -> qemuwrapper-cross
After this change:
nativesdk-glib-2.0 -> nativesdk-qemuwrapper-cross
This can fix do_populate_sdk failure complaining missing of
nativesdk-qemuwrapper. Error message is like below:
NOTE: > Executing update_gio_module_cache-nativesdk intercept ...
NOTE: Exit code 127. Output:
/xxx/lib32-core-image-sato/1.0/intercept_scripts-xxxx/
update_gio_module_cache-nativesdk: 13: nativesdk-qemuwrapper: not found
(From OE-Core rev: 89ac78e68c4be6e6163223c99e140e7530a61e8e)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The nativesdk class overrides PACKAGE_ARCH and unsets TUNE_FEATURES, but
as recipes might want to look at TUNE_PKGARCH too (for example, when
setting QEMU_EXTRAOPTIONS) we should also override that variable.
Otherwise, a nativesdk recipe will have the TUNE_PKGARCH of the target,
which leads to errors (eg passing mips arguments to an arm qemu).
(From OE-Core rev: 05322beb290e1db30bef49b4364f8a8e6e9f7408)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're currently encouraging an "arms race" with the FLAGS variables since
a recipe might want to set a specific flag for all variants but to do so,
+= won't work due to the assignment in the native/nativesdk class files. This
means recipes are using append.
Since the default variables are constructed out of TARGET_XXX variables and
we redefine these, there is no need to re-define the un-prefixed variables. If
we drop that, the += appends and similar work and recipes don't have to resort
to append.
Change the classes and cleanup a number of recipes to adapt to the change. This
change will result in some flags appearing to some native/nativesdk variants
but that is probably what was originally expected anyway.
(From OE-Core rev: a157b2f9d93428ca21265cc860a3b58b3698b3aa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is actually a use for nativesdk MACHINE_FEATURES; for example
qemu-usermode being supported, as this is needed to build profile-guided
optimised code.
We shouldn't use the target MACHINE_FEATURES for this because the target
and the SDK can be entirely different, so instead set the
MACHINE_FEATURES in nativesdk.bbclass to SDK_MACHINE_FEATURES (which
defaults to "") and let the conf/machine-sdk/*.conf files set that as
appropriate.
(From OE-Core rev: 14571764b7e046507f81bbe589a9f42c5b16665a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Link: https://lore.kernel.org/r/20231221170159.1995650-2-ross.burton@arm.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nativesdk aims to run in a slightly different environment than the
target build, so it resets MACHINE_FEATURES and filters DISTRO_FEATURES
with DISTRO_FEATURES_NATIVESDK.
However, feature backfill happens _after_ these operations:
$ bitbake-getvar -r nativesdk-glib-2.0 MACHINE_FEATURES
#
# $MACHINE_FEATURES [5 operations]
# set /home/ross/Yocto/poky/meta/conf/machine/include/qemu.inc:14
# "alsa bluetooth usbgadget screen vfat"
# set /home/ross/Yocto/poky/meta/conf/documentation.conf:284
# [doc] "Specifies the list of hardware features the MACHINE supports."
# set? /home/ross/Yocto/poky/meta/conf/bitbake.conf:893
# ""
# set /home/ross/Yocto/poky/meta/classes-recipe/nativesdk.bbclass:18
# ""
# append utils.py:132 [features_backfill]
# " rtc qemu-usermode"
# pre-expansion value:
# " rtc qemu-usermode"
MACHINE_FEATURES=" rtc qemu-usermode"
This is not intentional nor desired as the target machine features are
unrelated to the nativesdk environment.
(From OE-Core rev: f560ac0a5ccced02b84df337f0f26209cd4b6474)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Link: https://lore.kernel.org/r/20231221170159.1995650-1-ross.burton@arm.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
