linux/poky.git/meta/classes-recipe/cml1.bbclass, branch master

The poky repository master branch is no longer being updated.

2025-11-07T13:31:53+00:00

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

cml1.bbclass: use consistent make flags for menuconfig

2025-03-03T18:01:29+00:00

The class called 'make menuconfig' without any of the make variables and options set in EXTRA_OEMAKE, resulting in a quite different build environment than actually intended. For the kernel.bbclass this was fixed in commit 8c616bc0 ("kernel: Use consistent make flags for menuconfig") by appending ${EXTRA_OEMAKE} to KCONFIG_CONFIG_COMMAND. Instead of fixing this individually for additional recipes, we simply include ${EXTRA_OEMAKE} in KCONFIG_CONFIG_COMMAND by default. For most class users, this change is directly visible in the generated .config file: * For barebox and u-boot, the CONFIG_GCC_VERSION erroneously reflected the host GCC version before where it now correctly reflects the target toolchain's GCC. * For u-boot, also the "Compiler: " line at the beginning of the .config now prints the target toolchain instead of the host ones. * The kernel had this already set. * busybox did not produce any difference. Note that these projects might base some compile-time decisions on e.g. the actual compiler version used. Having the wrong one in the menuconfig-generated .config affects at least the visibility and consistency. Reported-by: Ulrich Ölmann (From OE-Core rev: 1b6ddd452837e67b500a84455a234f5edc8250a9) Signed-off-by: Enrico Jörns Signed-off-by: Richard Purdie

cml1.bbclass: do not escape the exit value

2025-02-27T10:55:17+00:00

Remove incorrectly escaped exit value, which causes error handling logic not to run. [YOCTO #15731] (From OE-Core rev: 5c44a9154f0cd4252d4840d836e6936393b5d3a3) Signed-off-by: Sven Kalmbach Signed-off-by: Richard Purdie

cml1.bbclass: do_diffconfig: Don't override .config with .config.orig

2024-10-11T11:17:03+00:00

Fixed: 1) $ bitbake virtual/kernel -cmenuconfig Do some changes and save the new config to default .config. 2) $ bitbake virtual/kernel -cdiffconfig The config fragment is dumped into ${WORKDIR}/fragment.cfg. But the .config which was saved by step #1 is overridden by .config.orig, so the changes will be lost if run 'bitbake virtual/kernel' And the following comment is for subprocess.call(), not for shutil.copy(), so move subprocess.call() to the correct location. # No need to check the exit code as we know it's going to be # non-zero, but that's what we expect. (From OE-Core rev: 6cccf6b02f92dad514e65fd779ff659b19eb6be7) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

cml1: add do_savedefconfig

2024-09-05T20:48:47+00:00

Move the do_savedefconfig task definition from u-boot and kernel to cml1.bbclass. There are more recipes which use the kbuild framework and benefit from a do_savedefconfig task. (From OE-Core rev: 2b2ed48903e09196ee20da7f66b1d3689e4a4473) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

cml1: prompt location of updated .config after do_menuconfig()

2024-03-30T22:25:43+00:00

When modifying the kernel config by invoking '-c menuconfig' manually, a sensible next step is to persist this changed configuration somewhere. A way to do this is to copy the generated .config back to the original config location. For this purpose, emit a copy+pasteable printout of the saved .config path similar to what we have for the fragment location in the 'diffconfig' task already. Example output: | Changed configuration saved at: | /path/to/bsp/build/tmp/work/my-machine-oe-linux/linux-custom/6.6.4/build/.config | Recompile will be forced (From OE-Core rev: b104470763b081f040f4fcac564136fc5562f23b) Signed-off-by: Enrico Jörns Signed-off-by: Richard Purdie

cml1: remove needless check for write_taint attribute

2024-03-30T22:25:43+00:00

The 'FIXME' comment itself says to remove this once the minimum bitbake version has been bumped. This was in 2012. The function was introduced in bitbake commit f7b55a94 ("bitbake: bitbake: ensure -f causes dependent tasks to be re-run") and is already part of bitbake 1.15.3 which is the minimum bitbake version since 'danny'. Remove the check. (From OE-Core rev: 035fe46fbf57ca83baf6610482ee7ee83c825a06) Signed-off-by: Enrico Jörns Signed-off-by: Richard Purdie

cml1: Fix KCONFIG_CONFIG_COMMAND not conveyed fully in do_menuconfig

2023-09-02T10:47:50+00:00

Variable overrides in KCONFIG_CONFIG_COMMAND do not work as expected due to double quote mismatches. The issue is reproducible in an environment where gold is the default linker. Below is an example snippet of run.do_terminal generated by do_menuconfig. do_terminal() { exec sh -c "make menuconfig CC="aarch64-webos-linux-gcc ..." LD="aarch64-webos-linux-ld.bfd ..." ... } Although LD override is set to bfd correctly, it is not passed to make and make menuconfig ends up with messages like: | gold linker is not supported as it is not capable of linking the kernel proper. | scripts/Kconfig.include:56: Sorry, this linker is not supported. (From OE-Core rev: 9c483765db762dbe8020423c8778518612b7e5f7) Signed-off-by: Jaeyoon Jung Signed-off-by: Richard Purdie

cml1: add showconfig task to easily find the generated .config file

2023-07-10T10:36:34+00:00

It's not that unusual to want to manually review the generated .config file after do_configure has ran. Add a new 'showconfig' task that simply prints the full path to the .config file, so the user can open it in an editor. (From OE-Core rev: 7edd3cd80ce6b705cfcf5ab794e809303745b951) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: introduce KCONFIG_CONFIG_ENABLE_MENUCONFIG

2023-06-09T12:55:21+00:00

Currently, uboot do_menuconfig task is breaking when UBOOT_CONFIG is chosen rather than UBOOT_MACHINE, it simply fails with the following errors: | make: *** No rule to make target 'menuconfig'. Stio. | Command failed. | Press any key to continue... this is due to the work directory of do_menuconfig is set to ${B} but not ${B}/$config. We should distinguish two situations: 1) When there is only one config item in UBOOT_CONFIG, do_menuconfig should work just like how it works for UBOOT_MACHINE. 2) When there are multiple config items in UBOOT_CONFIG, do_menuconfig should print out some information saying it's not supported other than just failing. This patch mainly aims to fix that by introducing a extra variable KCONFIG_CONFIG_ENABLE_MENUCONFIG, it would be set to 'false' for situation 2), and when it's set to 'true', then set KCONFIG_CONFIG_ROOTDIR correctly in uboot-config.bbclass to let do_menuconfig task work. DEVTOOL_DISABLE_MENUCONFIG could be replaced by this new variable KCONFIG_CONFIG_ENABLE_MENUCONFIG. (From OE-Core rev: f9e834e317880cf47dbb4f8285bc36d743beae5e) Signed-off-by: Ming Liu Signed-off-by: Richard Purdie