Date   

Re: meta-intel stuck on bootup #yocto

Dan O'Donovan
 

If you are using the meta-intel layer, you could also change your MACHINE to 'intel-corei7-64' instead of 'genericx86-64'.  I'm not sure if it will fix your specific issue but it will at least allow you to benefit from some of the additional features and patches and other tweaks that the meta-intel layer provides.


[meta-zephyr][PATCH 2/2] zephy-kernel-test: update the testcase list for x86

Naveen Saini
 

Updated the test recipes to build against Zephyr v2.0
Code clean up

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
classes/zephyrtest.bbclass | 2 +-
recipes-kernel/zephyr-kernel/zephyr-image.inc | 9 +-
.../zephyr-kernel/zephyr-kernel-test-all.bb | 1 -
.../zephyr-kernel/zephyr-kernel-test.inc | 89 ++++++++++---------
4 files changed, 53 insertions(+), 48 deletions(-)

diff --git a/classes/zephyrtest.bbclass b/classes/zephyrtest.bbclass
index 8a051db..3acc4c3 100644
--- a/classes/zephyrtest.bbclass
+++ b/classes/zephyrtest.bbclass
@@ -14,7 +14,7 @@ python zephyrtest_virtclass_handler () {
e.data.setVar("ZEPHYR_IMAGENAME", pn + ".elf")

# Most tests for Zephyr 1.6 are in the "legacy" folder
- e.data.setVar("ZEPHYR_IMAGE_SRCDIR", "tests/legacy/kernel/" + variant)
+ e.data.setVar("ZEPHYR_SRC_DIR", "tests/kernel/" + variant)
e.data.setVar("ZEPHYR_MAKE_OUTPUT", "zephyr.elf")

# Allow to build using both foo-some_test form as well as foo-some-test
diff --git a/recipes-kernel/zephyr-kernel/zephyr-image.inc b/recipes-kernel/zephyr-kernel/zephyr-image.inc
index cf57dbf..e8b8871 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-image.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-image.inc
@@ -7,14 +7,11 @@ inherit deploy
QEMU_BIN_PATH = "${STAGING_BINDIR_NATIVE}"

ZEPHYR_BASE = "${S}"
-
-do_compile () {
- cd ${S}
- oe_runmake ${ZEPHYR_MAKE_ARGS} -C ${ZEPHYR_IMAGE_SRCDIR}
-}
+OECMAKE_SOURCEPATH = "${S}/${ZEPHYR_SRC_DIR}"

do_deploy () {
- install -D ${ZEPHYR_IMAGE_SRCDIR}/outdir/${BOARD}/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${ZEPHYR_IMAGENAME}
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${ZEPHYR_IMAGENAME}
}

addtask deploy after do_compile
+do_install[noexec] = "1"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test-all.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-test-all.bb
index c45124a..85efd24 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test-all.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test-all.bb
@@ -4,7 +4,6 @@ INHIBIT_DEFAULT_DEPS = "1"
require zephyr-kernel-test.inc

addtask testimage
-deltask configure
deltask compile
deltask install

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index 6e96ae2..d7572ef 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -1,52 +1,61 @@
+ZEPHYRTESTS_remove = "fifo fp_sharing lifo mbox mem_heap mem_pool \
+ mem_protect mem_slab msgq mutex pipe profiling sched semaphore \
+ stack threads tickless timer workq"
+
+
+# Exclude tests which does not build for various reasons
+ZEPHYRTESTS_remove = "gen_isr_table spinlock smp mp"

-ZEPHYRTESTS_remove = "test_static_idt test_fifo test_fp_sharing \
- test_sema test_stackprot test_obj_tracing test_stack \
- test_tickless test_timer"

# test_context will fail because QEMU for ARM does not emulate CortexM3 BASEPRI register
-ZEPHYRTESTS_remove_arm += "test_context"
+#ZEPHYRTESTS_remove_arm += ""

# test_critical never finishes in an unpatched QEMU either
-ZEPHYRTESTS_remove_arm += "test_critical"
+#ZEPHYRTESTS_remove_arm += ""

#Remove ARM specific tests
-ZEPHYRTESTS_remove_x86 += "test_context test_arm_irq_vector_table"
+#ZEPHYRTESTS_remove_x86 += ""

#Remove tests not intended for Nios2
-ZEPHYRTESTS_remove_nios2 += "test_context test_mem_safe"
+#ZEPHYRTESTS_remove_nios2 += ""

-# List of all available tests
+# List of all available kernel tests
ZEPHYRTESTS = " \
- test_context \
- test_critical \
- test_early_sleep \
- test_errno \
- test_events \
- test_fifo \
- test_fifo_priv \
- test_fp_sharing \
- test_libs \
- test_lifo \
- test_mail \
- test_mail_priv \
- test_map \
- test_map_priv \
- test_mem_safe \
- test_mutex \
- test_nano_work \
- test_obj_tracing \
- test_pend \
- test_pipe \
- test_pipe_priv \
- test_pool \
- test_sema \
- test_sema_priv \
- test_sleep \
- test_stack \
- test_stackprot \
- test_static_idt \
- test_task \
- test_task_priv \
- test_tickless \
- test_timer \
+ boot_page_table \
+ common \
+ context \
+ critical \
+ device \
+ early_sleep \
+ fatal \
+ fifo \
+ fp_sharing \
+ gen_isr_table \
+ interrupt \
+ lifo \
+ mbox \
+ mem_heap \
+ mem_pool \
+ mem_protect \
+ mem_slab \
+ mp \
+ msgq \
+ mutex \
+ obj_tracing \
+ pending \
+ pipe \
+ poll \
+ profiling \
+ queue \
+ sched \
+ semaphore \
+ sleep \
+ smp \
+ spinlock \
+ stack \
+ threads \
+ tickless \
+ timer \
+ workq \
+ xip \
"
--
2.17.1


[meta-zephyr][PATCH 1/2] zephyr.conf: Enable uninative

Naveen Saini
 

Use uninative by default to allow to build multiple distro
and re-use sstate cache

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/distro/zephyr.conf | 2 ++
1 file changed, 2 insertions(+)

diff --git a/conf/distro/zephyr.conf b/conf/distro/zephyr.conf
index 580ae2a..673152f 100644
--- a/conf/distro/zephyr.conf
+++ b/conf/distro/zephyr.conf
@@ -14,3 +14,5 @@ TEST_SUITES = "zephyr"
TOOLCHAIN_TARGET_TASK += " newlib"
INHERIT += "siteinfo-zephyr"

+INHERIT += "uninative"
+require conf/distro/include/yocto-uninative.inc
--
2.17.1


Re: Build issue - newbie

Morne
 

Please let me know how to check YP version.
In the directory that you checked out the git repo, open the following file:

poky/meta-poky/conf/distro/poky.conf

At the top of the file it will show DISTRO_VERSION and DISTRO_CODENAME

I suspect that you are using different branches of the git repo in the instance where it works, and the instance where it doesn't work.

- Morné


Re: Build issue - newbie

Sujoy Ray
 

Please let me know how to check YP version.


Re: Build issue - newbie

Sujoy Ray
 

I have used the steps described in https://github.com/openbmc/openbmc.
This works in native Ubuntu installation. But fails under VMWare.


Re: Build issue - newbie

Morne
 

ERROR: Layer microsoft-layer is not compatible with the core layer which only supports these series: zeus (layer is compatible with warrior)

The above error happens when I run bitbake obmc-phosphor-image in Ubuntu 16.04 running in VMwarer ( Windows 10 as HOST).
The above command succeeds when I use Ubuntu native installation.
What YP version are you using ?

Can you verify that you are using the same YP version in both cases ?

- Morné


Re: Build issue - newbie

Khem Raj
 

On 12/11/19 9:59 PM, Sujoy Ray wrote:
Hello,
I am trying to build yocto project and having following error:
==========================
ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/home/sujoy/OpenBMC/openbmc/build/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 2104 at 2019-12-11 19:23:03.474760 ---
ERROR: Layer microsoft-layer is not compatible with the core layer which only supports these series: zeus (layer is compatible with warrior)
=============================================
The above error happens when I run /bitbake obmc-phosphor-image/ in Ubuntu 16.04 running in VMwarer ( Windows 10 as HOST).
The above command succeeds when I use Ubuntu native installation.
Could anybody please help?
it seems your project has mixed releases of different layers. So please describe how you setup your project. Usually you should be using same release/branch for all layers, unless a layer states otherwise

Thanks,
Sujoy.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#47646): https://lists.yoctoproject.org/g/yocto/message/47646
Mute This Topic: https://lists.yoctoproject.org/mt/68263780/1997914
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [raj.khem@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [meta-rockchip][PATCH] rk3288: Convert to using wic

Trevor Woerner
 

Super awesome! Applied, thanks :-)


Build issue - newbie

Sujoy Ray
 

Hello,
I am trying to build yocto project and having following error:
==========================
ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/home/sujoy/OpenBMC/openbmc/build/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 2104 at 2019-12-11 19:23:03.474760 ---
ERROR: Layer microsoft-layer is not compatible with the core layer which only supports these series: zeus (layer is compatible with warrior)
=============================================
 
The above error happens when I run bitbake obmc-phosphor-image in Ubuntu 16.04 running in VMwarer ( Windows 10 as HOST).
 
The above command succeeds when I use Ubuntu native installation. 

Could anybody please help?
Thanks,
Sujoy.


[meta-rockchip][PATCH] rk3288: Convert to using wic

Joshua Watt
 

Coverts the firefly-rk3288, tinker-rk3288, and vyasa-rk3288 machines to
use wic instead of the rockchip-gpt-img class. The rock2-squared machine
has to keep the older image class because u-boot doesn't provided a
combined idbloader for it.

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/firefly-rk3288.conf | 15 ++++++++++++++-
conf/machine/include/rk3288.inc | 2 --
conf/machine/rock2-square.conf | 6 ++++++
conf/machine/tinker-rk3288.conf | 15 ++++++++++++++-
conf/machine/vyasa-rk3288.conf | 14 ++++++++++++++
wic/firefly-rk3288.wks | 26 ++++++++++++++++++++++++++
wic/tinker-rk3288.wks | 26 ++++++++++++++++++++++++++
wic/vyasa-rk3288.wks | 27 +++++++++++++++++++++++++++
8 files changed, 127 insertions(+), 4 deletions(-)
create mode 100644 wic/firefly-rk3288.wks
create mode 100644 wic/tinker-rk3288.wks
create mode 100644 wic/vyasa-rk3288.wks

diff --git a/conf/machine/firefly-rk3288.conf b/conf/machine/firefly-rk3288.conf
index 0900440..71e0bc3 100644
--- a/conf/machine/firefly-rk3288.conf
+++ b/conf/machine/firefly-rk3288.conf
@@ -10,4 +10,17 @@ require conf/machine/include/rk3288.inc

KERNEL_DEVICETREE = "rk3288-firefly.dtb"
UBOOT_MACHINE = "firefly-rk3288_defconfig"
-GPTIMG_APPEND = "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
+
+WKS_FILE = "firefly-rk3288.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index 6e9a09a..b261692 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -12,5 +12,3 @@ SERIAL_CONSOLES = "115200;ttyS2"
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
SPL_BINARY ?= "idbloader.img"

-IMAGE_FSTYPES += "rockchip-gpt-img"
-IMAGE_CLASSES += "rockchip-gpt-img"
diff --git a/conf/machine/rock2-square.conf b/conf/machine/rock2-square.conf
index 737d3ae..46064ee 100644
--- a/conf/machine/rock2-square.conf
+++ b/conf/machine/rock2-square.conf
@@ -11,3 +11,9 @@ require conf/machine/include/rk3288.inc
SPL_BINARY = "u-boot-spl-dtb.bin"
KERNEL_DEVICETREE = "rk3288-rock2-square.dtb"
UBOOT_MACHINE = "rock2_defconfig"
+
+# This board doesn't support the combined idbloader, so resort to the older
+# image class
+IMAGE_FSTYPES += "rockchip-gpt-img"
+IMAGE_CLASSES += "rockchip-gpt-img"
+
diff --git a/conf/machine/tinker-rk3288.conf b/conf/machine/tinker-rk3288.conf
index 9e23f8d..e460d43 100644
--- a/conf/machine/tinker-rk3288.conf
+++ b/conf/machine/tinker-rk3288.conf
@@ -9,4 +9,17 @@ require conf/machine/include/rk3288.inc

KERNEL_DEVICETREE = "rk3288-tinker.dtb"
UBOOT_MACHINE = "tinker-rk3288_defconfig"
-GPTIMG_APPEND = "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
+
+WKS_FILE = "tinker-rk3288.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/conf/machine/vyasa-rk3288.conf b/conf/machine/vyasa-rk3288.conf
index bfbd09b..03a436a 100644
--- a/conf/machine/vyasa-rk3288.conf
+++ b/conf/machine/vyasa-rk3288.conf
@@ -12,3 +12,17 @@ KERNEL_DEVICETREE = "rk3288-vyasa.dtb"
KERNEL_EXTRA_ARGS += "LOADADDR=0x02000000"

UBOOT_MACHINE = "vyasa-rk3288_defconfig"
+
+WKS_FILE = "vyasa-rk3288.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/wic/firefly-rk3288.wks b/wic/firefly-rk3288.wks
new file mode 100644
index 0000000..5013aea
--- /dev/null
+++ b/wic/firefly-rk3288.wks
@@ -0,0 +1,26 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 -
+#
+
+part loader1 --ondisk mmcblk0 --align 32 --size 4000K --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --ondisk mmcblk0 --align 4032 --size 64K
+part reserved2 --ondisk mmcblk0 --align 4096 --size 4096K
+part loader2 --ondisk mmcblk0 --align 8192 --size 4096K --source rawcopy --sourceparams="file=u-boot.bin"
+part atf --ondisk mmcblk0 --align 12288 --size 4096K
+part /boot --ondisk mmcblk0 --align 16384 --size=114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk mmcblk0 --align 131072 --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/tinker-rk3288.wks b/wic/tinker-rk3288.wks
new file mode 100644
index 0000000..5013aea
--- /dev/null
+++ b/wic/tinker-rk3288.wks
@@ -0,0 +1,26 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 -
+#
+
+part loader1 --ondisk mmcblk0 --align 32 --size 4000K --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --ondisk mmcblk0 --align 4032 --size 64K
+part reserved2 --ondisk mmcblk0 --align 4096 --size 4096K
+part loader2 --ondisk mmcblk0 --align 8192 --size 4096K --source rawcopy --sourceparams="file=u-boot.bin"
+part atf --ondisk mmcblk0 --align 12288 --size 4096K
+part /boot --ondisk mmcblk0 --align 16384 --size=114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk mmcblk0 --align 131072 --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk0p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/vyasa-rk3288.wks b/wic/vyasa-rk3288.wks
new file mode 100644
index 0000000..3fc9a5b
--- /dev/null
+++ b/wic/vyasa-rk3288.wks
@@ -0,0 +1,27 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 -
+#
+
+part loader1 --ondisk mmcblk2 --align 32 --size 4000K --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --ondisk mmcblk2 --align 4032 --size 64K
+part reserved2 --ondisk mmcblk2 --align 4096 --size 4096K
+part loader2 --ondisk mmcblk2 --align 8192 --size 4096K --source rawcopy --sourceparams="file=u-boot.bin"
+part atf --ondisk mmcblk2 --align 12288 --size 4096K
+part /boot --ondisk mmcblk2 --align 16384 --size=114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk mmcblk2 --align 131072 --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk2p7 rootfstype=ext4 init=/sbin/init"
+
--
2.23.0


Re: variable and task/function timing

Nicolas Dechesne
 

On Wed, Dec 11, 2019 at 5:41 PM Trevor Woerner <twoerner@...> wrote:

On Wed 2019-12-11 @ 04:49:27 PM, Nicolas Dechesne wrote:
right.. I was confused, I missed a few things in your email (well, it
was really long ;).
lol
Apparently writing long emails is therapeutic for me.

I'm sure some will say "there's your solution, do it that way, problem
solved". However, I think "debug/release" are much more natural than
"plain/debugoptimized". I can't change the MESON_BUILDTYPE strings,
they have to be one of those two, so I introduced MESA_BUILD_TYPE as a
level-of-indirection above MESON_BUILDTYPE to allow the user to use the more
natural "debug/release" wording.

So my real question is (and maybe I'm just yak shaving at this point): given
the row/column view of variable setting, how do we factor in the element of
time? For example, *when* do the variables referenced by anonymous python
functions and by tasks get set?

This works (but doesn't allow me the space for nice error checking):

MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"

and this doesn't:

python do_check_build_type() {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
bb.plain("setting meson build type to debugoptimized")
}
addtask check_build_type before do_configure
I missed the fact that you were using a task.
You can probably call do_check_build_type() when setting
MESON_BUILDTYPE instead of using a task, e.g. something like this:
MESON_BUILDTYPE = "${@do_check_build_type(d.getVar('MESA_BUILD_TYPE'))}"
I did propose a 3rd way (in the original email) which does work which is very
similar to what you're suggesting:

# set the build type to either 'release' or 'debug'
# the upstream mesa sources actually build a debug release by default
# but here we assume the user will want a release build by default
MESA_BUILD_TYPE ?= "release"
def check_buildtype(d):
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
#bb.plain("setting meson build type to debugoptimized")
return 'debugoptimized'
return 'plain'
MESON_BUILDTYPE = "${@check_buildtype(d)}"

The user experience is rather different though. Let's say the user sets the
following in conf/local.conf:

MESA_BUILD_TYPE = "hello"

Using the "addtask" method (which doesn't work) produces a very nice error
message:

$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
Parsing recipes: 100% |#######################################################################################################################| Time: 0:00:01
Parsing of 1528 .bb files complete (1524 cached, 4 parsed). 2259 targets, 103 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "opensuseleap-15.1"
TARGET_SYS = "arm-oe-linux-gnueabi"
MACHINE = "tinker-rk3288"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
meta-rockchip = "master:e8fd1f92ed59e0e71a7418779b912c5da342495c"
meta-tweaks = "master:b9184893949356a2da43bb2b5ec88dd573a5db0d"
meta = "master:093a1971f2ae12e1f514598da984f268607e550b"
meta-oe = "master:851321744e17e51aeb822a8d88c3532dffdf1cef"

Initialising tasks: 100% |####################################################################################################################| Time: 0:00:00
Sstate summary: Wanted 0 Found 0 Missed 0 Current 77 (0% match, 100% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: mesa-2_19.2.4-r0 do_check_build_type: unknown build type (hello), please set to either 'release' or 'debug'
ERROR: Logfile of failure stored in: /z/build-master/tinker-rk3288/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/mesa/2_19.2.4-r0/temp/log.do_check_build_type.12869
ERROR: Task (/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb:do_check_build_type) failed with exit code '1'
NOTE: Tasks Summary: Attempted 606 tasks of which 603 didn't need to be rerun and 1 failed.

Using the method proposed above produces:

$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug' ETA: --:--:--
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug'
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb
ERROR: ExpansionError during parsing /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
Traceback (most recent call last):
File "Var <MESON_BUILDTYPE>", line 1, in <module>
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa.inc", line 56, in check_buildtype(d=<bb.data_smart.DataSmart object at 0x7ffac8d0f4a8>):
if _buildtype not in ['release', 'debug']:
> bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/bitbake/lib/bb/__init__.py", line 108, in fatal:
mainlogger.critical(''.join(args), extra=kwargs)
> raise BBHandledException()

bb.data_smart.ExpansionError: Failure expanding variable MESON_BUILDTYPE, expression was ${@check_buildtype(d)} which triggered exception BBHandledException:


Summary: There were 4 WARNING messages shown.
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
then you could use an anonymous python function instead.

python () {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to
either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
}

or something along these lines. that would be done during parsing, so
the variable should be set for all tasks.


Re: [yocto-docs][PATCH] ref-manual: mention PREPROCESS_RELOCATE_DIRS variable

Martin Jansa
 

ping again


On Fri, Sep 6, 2019 at 1:32 PM Martin Jansa <martin.jansa@...> wrote:
On Mon, Aug 12, 2019 at 07:51:40PM +0000, Martin Jansa wrote:
> Signed-off-by: Martin Jansa <Martin.Jansa@...>

ping

> ---
>  documentation/ref-manual/ref-classes.xml   |  5 ++++-
>  documentation/ref-manual/ref-variables.xml | 21 +++++++++++++++++++++
>  2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
> index ece47e757..159efb3b1 100644
> --- a/documentation/ref-manual/ref-classes.xml
> +++ b/documentation/ref-manual/ref-classes.xml
> @@ -413,7 +413,10 @@
>          <filename>cross</filename>, and
>          <filename>cross-canadian</filename> recipes to change
>          <filename>RPATH</filename> records within binaries in order to make
> -        them relocatable.
> +        them relocatable. To extend the list of directories where it searches
> +        for binaries to relocate, you can set
> +        <link linkend='var-PREPROCESS_RELOCATE_DIRS'><filename>PREPROCESS_RELOCATE_DIRS</filename></link>
> +        variable in your recipe.
>      </para>
>  </section>

> diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
> index 9470a780a..5ac766658 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -11424,6 +11424,27 @@
>              </glossdef>
>          </glossentry>

> +        <glossentry id='var-PREPROCESS_RELOCATE_DIRS'><glossterm>PREPROCESS_RELOCATE_DIRS</glossterm>
> +            <info>
> +                PREPROCESS_RELOCATE_DIRS[doc] = "List of extra directories where to search for binaries which should be relocatable."
> +            </info>
> +            <glossdef>
> +                <para role="glossdeffirst">
> +<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
> +                    List of extra directories with binaries.
> +                </para>
> +
> +                <para>
> +                    <filename>PREPROCESS_RELOCATE_DIRS</filename> is used by
> +                    chrpath.bbclass to allow extending the list where it searches
> +                    for binaries. By default it searches in:
> +                    ${bindir} ${sbindir} ${base_sbindir} ${base_bindir} ${libdir} ${base_libdir} ${libexecdir}
> +                    Thus, <filename>PREPROCESS_RELOCATE_DIRS</filename> usually doesn't
> +                    need to be set withing recipes.
> +                </para>
> +            </glossdef>
> +        </glossentry>
> +
>          <glossentry id='var-PRIORITY'><glossterm>PRIORITY</glossterm>
>              <info>
>                  PRIORITY[doc] = "Indicates the importance of a package.  The default value is 'optional'.  Other standard values are 'required', 'standard', and 'extra'."
> --
> 2.17.1
>

--
Martin 'JaMa' Jansa     jabber: Martin.Jansa@...


[PATCH 2/2] ref-manual: Update the documentation for USERADD_ERROR_DYNAMIC

Peter Kjellerstedt
 

* Update USERADD_ERROR_DYNAMIC[doc] and the first paragraph to match
the definition in meta/conf/documentation.conf.
* Add a note explaining the differences in behavior when setting
USERADD_ERROR_DYNAMIC to "warn" and "error" respectively.

[YOCTO #12932]

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@...>
---
documentation/ref-manual/ref-variables.xml | 33 ++++++++++++++++------
1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index e6009926be..c8ece0c579 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -16770,18 +16770,21 @@

<glossentry id='var-USERADD_ERROR_DYNAMIC'><glossterm>USERADD_ERROR_DYNAMIC</glossterm>
<info>
- USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in files/passwd and files/group files. If set to 'warn', a warning will be issued instead."
+ USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in any of the files listed in USERADD_UID_TABLES and USERADD_GID_TABLES. If set to 'warn', a warning will be issued instead."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- If set to "error", forces the OpenEmbedded build system to
- produce an error if the user identification
- (<filename>uid</filename>) and group identification
- (<filename>gid</filename>) values are not defined
- in <filename>files/passwd</filename>
- and <filename>files/group</filename> files.
- If set to "warn", a warning will be issued instead.
+
+ If set to <filename>error</filename>, forces the
+ OpenEmbedded build system to produce an error if the user
+ identification (<filename>uid</filename>) and group
+ identification (<filename>gid</filename>) values are not
+ defined in any of the files listed
+ in <link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link>
+ and <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>. If
+ set to <filename>warn</filename>, a warning will be issued
+ instead.
</para>

<para>
@@ -16808,6 +16811,20 @@
<link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>
variables.
</para>
+
+ <note>
+ There is a difference in behavior between
+ setting <filename>USERADD_ERROR_DYNAMIC</filename>
+ to <filename>error</filename> and setting it
+ to <filename>warn</filename>. When it is set
+ to <filename>warn</filename>, the build system will report a
+ warning for every undefined <filename>uid</filename> and
+ <filename>gid</filename> in any recipe. But when it is set
+ to <filename>error</filename>, it will only report errors
+ for recipes that are actually built. This saves you from
+ having to add static IDs for recipes that you know will
+ never be built.
+ </note>
</glossdef>
</glossentry>

--
2.21.0


[PATCH 1/2] ref-manual: Add missing/remove extraneous quotes

Peter Kjellerstedt
 

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@...>
---
documentation/ref-manual/migration.xml | 4 ++--
documentation/ref-manual/ref-variables.xml | 20 +++++++++-----------
2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml
index 8d50ab9133..2052188b6b 100644
--- a/documentation/ref-manual/migration.xml
+++ b/documentation/ref-manual/migration.xml
@@ -2110,7 +2110,7 @@
such as the following:
<literallayout class='monospaced'>
inherit bluetooth
- PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
+ PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
</literallayout>
@@ -3624,7 +3624,7 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.
image types, this part of the kernel image base name as been
removed leaving only the following:
<literallayout class='monospaced'>
- KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}
+ KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
</literallayout>
If you have recipes or classes that use
<filename>KERNEL_IMAGE_BASE_NAME</filename> directly, you might
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 02abc590cd..e6009926be 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -367,7 +367,7 @@

<glossentry id='var-ASSUME_SHLIBS'><glossterm>ASSUME_SHLIBS</glossterm>
<info>
- ASSUME_SHLIBS[doc] = Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system."
+ ASSUME_SHLIBS[doc] = "Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -1423,7 +1423,7 @@
Use the following format to export the variable to the
BitBake environment:
<literallayout class='monospaced'>
- export BBSERVER=localhost:$port"
+ export BBSERVER=localhost:$port
</literallayout>
</para>

@@ -3786,7 +3786,7 @@
It is not intended to be user-configurable.
It is best to just reference the variable to see which distro features are
being backfilled for all distro configurations.
- See the <link linkend='ref-features-backfill'>Feature Backfilling</link> section for
+ See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
more information.
</para>
</glossdef>
@@ -11054,7 +11054,7 @@

<glossentry id='var-PN'><glossterm>PN</glossterm>
<info>
- PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package.
+ PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -13383,8 +13383,7 @@

<glossentry id='var-SKIP_FILEDEPS'><glossterm>SKIP_FILEDEPS</glossterm>
<info>
- SKIP_FILEDEPS[doc] = "Enables you to remove all files from
- the "Provides" section of an RPM package."
+ SKIP_FILEDEPS[doc] = "Enables you to remove all files from the 'Provides' section of an RPM package."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -15331,7 +15330,7 @@

<glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
<info>
- TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or "newlib."
+ TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or 'newlib'."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -16473,7 +16472,7 @@
Appends a string to the name of the local version of the
U-Boot image.
For example, assuming the version of the U-Boot image
- built was "2013.10, the full version string reported by
+ built was "2013.10", the full version string reported by
U-Boot would be "2013.10-yocto" given the following
statement:
<literallayout class='monospaced'>
@@ -17108,7 +17107,7 @@
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
section in the Yocto Project Development Tasks Manual.
For details on the kickstart file format, see the
- "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>
+ "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>"
Chapter.
</para>
</glossdef>
@@ -17178,8 +17177,7 @@

<glossentry id='var-XSERVER'><glossterm>XSERVER</glossterm>
<info>
- XSERVER[doc] = "Specifies the packages that should be installed
- to provide an X server and drivers for the current machine."
+ XSERVER[doc] = "Specifies the packages that should be installed to provide an X server and drivers for the current machine."
</info>
<glossdef>
<para role="glossdeffirst">
--
2.21.0


Re: variable and task/function timing

Trevor Woerner
 

On Wed 2019-12-11 @ 04:49:27 PM, Nicolas Dechesne wrote:
right.. I was confused, I missed a few things in your email (well, it
was really long ;).
lol
Apparently writing long emails is therapeutic for me.

I'm sure some will say "there's your solution, do it that way, problem
solved". However, I think "debug/release" are much more natural than
"plain/debugoptimized". I can't change the MESON_BUILDTYPE strings,
they have to be one of those two, so I introduced MESA_BUILD_TYPE as a
level-of-indirection above MESON_BUILDTYPE to allow the user to use the more
natural "debug/release" wording.

So my real question is (and maybe I'm just yak shaving at this point): given
the row/column view of variable setting, how do we factor in the element of
time? For example, *when* do the variables referenced by anonymous python
functions and by tasks get set?

This works (but doesn't allow me the space for nice error checking):

MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"

and this doesn't:

python do_check_build_type() {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
bb.plain("setting meson build type to debugoptimized")
}
addtask check_build_type before do_configure
I missed the fact that you were using a task.
You can probably call do_check_build_type() when setting
MESON_BUILDTYPE instead of using a task, e.g. something like this:
MESON_BUILDTYPE = "${@do_check_build_type(d.getVar('MESA_BUILD_TYPE'))}"
I did propose a 3rd way (in the original email) which does work which is very
similar to what you're suggesting:

# set the build type to either 'release' or 'debug'
# the upstream mesa sources actually build a debug release by default
# but here we assume the user will want a release build by default
MESA_BUILD_TYPE ?= "release"
def check_buildtype(d):
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
#bb.plain("setting meson build type to debugoptimized")
return 'debugoptimized'
return 'plain'
MESON_BUILDTYPE = "${@check_buildtype(d)}"

The user experience is rather different though. Let's say the user sets the
following in conf/local.conf:

MESA_BUILD_TYPE = "hello"

Using the "addtask" method (which doesn't work) produces a very nice error
message:

$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
Parsing recipes: 100% |#######################################################################################################################| Time: 0:00:01
Parsing of 1528 .bb files complete (1524 cached, 4 parsed). 2259 targets, 103 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "opensuseleap-15.1"
TARGET_SYS = "arm-oe-linux-gnueabi"
MACHINE = "tinker-rk3288"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
meta-rockchip = "master:e8fd1f92ed59e0e71a7418779b912c5da342495c"
meta-tweaks = "master:b9184893949356a2da43bb2b5ec88dd573a5db0d"
meta = "master:093a1971f2ae12e1f514598da984f268607e550b"
meta-oe = "master:851321744e17e51aeb822a8d88c3532dffdf1cef"

Initialising tasks: 100% |####################################################################################################################| Time: 0:00:00
Sstate summary: Wanted 0 Found 0 Missed 0 Current 77 (0% match, 100% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: mesa-2_19.2.4-r0 do_check_build_type: unknown build type (hello), please set to either 'release' or 'debug'
ERROR: Logfile of failure stored in: /z/build-master/tinker-rk3288/build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/mesa/2_19.2.4-r0/temp/log.do_check_build_type.12869
ERROR: Task (/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb:do_check_build_type) failed with exit code '1'
NOTE: Tasks Summary: Attempted 606 tasks of which 603 didn't need to be rerun and 1 failed.

Using the method proposed above produces:

$ bitbake mesa -c configure
Loading cache: 100% |#########################################################################################################################| Time: 0:00:00
Loaded 2257 entries from dependency cache.
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug' ETA: --:--:--
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
ERROR: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: unknown build type (hello), please set to either 'release' or 'debug'
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Exception during build_dependencies for meson_do_configure
WARNING: /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb: Error during finalise of /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa_19.2.4.bb
ERROR: ExpansionError during parsing /opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa-gl_19.2.4.bb
Traceback (most recent call last):
File "Var <MESON_BUILDTYPE>", line 1, in <module>
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/openembedded-core/meta/recipes-graphics/mesa/mesa.inc", line 56, in check_buildtype(d=<bb.data_smart.DataSmart object at 0x7ffac8d0f4a8>):
if _buildtype not in ['release', 'debug']:
> bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
File "/opt/oe/configs/z/build-master/tinker-rk3288/layers/bitbake/lib/bb/__init__.py", line 108, in fatal:
mainlogger.critical(''.join(args), extra=kwargs)
> raise BBHandledException()

bb.data_smart.ExpansionError: Failure expanding variable MESON_BUILDTYPE, expression was ${@check_buildtype(d)} which triggered exception BBHandledException:


Summary: There were 4 WARNING messages shown.
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.


Re: variable and task/function timing

Trevor Woerner
 

On Wed 2019-12-11 @ 03:48:51 PM, Richard Purdie wrote:
On Wed, 2019-12-11 at 10:39 -0500, Trevor Woerner wrote:
On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to
either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to
debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..."
line makes no difference. Probably because the variable is being set
by a task (which, I assume, is too late to have any effect, which is
a large part of why I wrote this email: when do these tasks get
called with respect to how variable are being set by all the
different ways they're being set?)
Tasks run in isolation, if you change the datastore in a task it has no
way to get "seen" by other tasks. They're separate processes.

That is why the setVar in a task has no effect outside that task.
Excellent, that explains a lot, thanks!

So in this case, the answer to the question of "when" is: never :-)


Re: variable and task/function timing

Nicolas Dechesne
 

On Wed, Dec 11, 2019 at 4:48 PM Richard Purdie
<richard.purdie@...> wrote:

On Wed, 2019-12-11 at 10:39 -0500, Trevor Woerner wrote:
On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to
either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to
debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..."
line makes no difference. Probably because the variable is being set
by a task (which, I assume, is too late to have any effect, which is
a large part of why I wrote this email: when do these tasks get
called with respect to how variable are being set by all the
different ways they're being set?)
Tasks run in isolation, if you change the datastore in a task it has no
way to get "seen" by other tasks. They're separate processes.
right... so my array is not 2D, but 3D then! but as i just said, i
missed the addtask in the first email.


That is why the setVar in a task has no effect outside that task.

Cheers,

Richard



Re: variable and task/function timing

Nicolas Dechesne
 

hey Trevor,

On Wed, Dec 11, 2019 at 4:39 PM Trevor Woerner <twoerner@...> wrote:

On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
On Wed, Dec 11, 2019 at 8:18 AM Trevor Woerner <twoerner@...> wrote:

Is there a document, or better yet a diagram, showing the order in which
various config files, recipes, tasks, etc are parsed?

Figuring out the order of the config files is easy enough (bitbake.conf), but
trying to figure out when various other parts are processed is just a guess
for me right now.
well the easiest way to visualize it is to think about all variables
being in a large array. Each variable (each row) having a different
'value' for each 'column' and each column representing a recipe. When
bitbake references a variable it is always in the context of a given
recipe, so you are looking at a specific 'column'. Initially this
array is filled with default values resulting from the parsing of all
global .conf files, as you noticed the list of conf files and the
order is set in bitbake.conf (which itself is hardcoded in bitbake,
and the first file to parse).

then bitbake will parse each recipe, one by one, and update each
variable's value in that array (in the relevant column). At the end of
the parsing, you have all variables which are known.

you can use bitbake -e to print variables value:

bitbake -e | grep ^MESON_BUILDTYPE

it will show you the default value (if it is set) outside the context
of any recipe.

bitbake -e <bar> | grep ^MESON_BUILDTYPE

will give you the value of this variable as it is set in <bar> recipe
Ooh, I like this already! Your row/column concept is a good mental map of the
process. Your explanation cleared up the "bitbake -e" vs "bitbake -e <bar>"
case for me too!

The content of the class is parsed when it is inherited. So you need
to initialize class variables *before* you inherit the class. e.g.

MESA_BUILD_TYPE ?= "release"
...
inherit meson

in your case is very different from
inherit meson
...
MESA_BUILD_TYPE ?= "release"

+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..." line makes
no difference. Probably because the variable is being set by a task (which, I
assume, is too late to have any effect, which is a large part of why I wrote
this email: when do these tasks get called with respect to how variable are
being set by all the different ways they're being set?)

You are
mixing BUILD_TYPE and BUILDTYPE in your email.. maybe you are mixing
that in your testing as well? What is set in local.conf will be parsed
first, so if you set a variable there, it will be 'set' when you parse
the recipe, so when you use ?= it should be a no-op.
Notice, though, that I'm using two different variables:

1) MESA_BUILD_TYPE: which can be set to "debug" or "release"
2) MESON_BUILDTYPE: which can be set to "plain" or "debugoptimized"

MESA_BUILD_TYPE is how the user tweaks the MESON_BUILDTYPE from the mesa
recipe. Given what you've said above, however, I can see now that (as you say)
setting:

MESON_BUILDTYPE_pn-mesa = ...

in conf/local.conf will do what I want since this variable is recipe-specific
and setting it in one recipe this way won't affect it in others.
right.. I was confused, I missed a few things in your email (well, it
was really long ;).


I'm sure some will say "there's your solution, do it that way, problem
solved". However, I think "debug/release" are much more natural than
"plain/debugoptimized". I can't change the MESON_BUILDTYPE strings,
they have to be one of those two, so I introduced MESA_BUILD_TYPE as a
level-of-indirection above MESON_BUILDTYPE to allow the user to use the more
natural "debug/release" wording.

So my real question is (and maybe I'm just yak shaving at this point): given
the row/column view of variable setting, how do we factor in the element of
time? For example, *when* do the variables referenced by anonymous python
functions and by tasks get set?

This works (but doesn't allow me the space for nice error checking):

MESON_BUILDTYPE = "${@bb.utils.contains('MESA_BUILD_TYPE', 'debug', 'debugoptimized', 'plain', d)}"

and this doesn't:

python do_check_build_type() {
_buildtype = d.getVar('MESA_BUILD_TYPE')
if _buildtype not in ['release', 'debug']:
bb.fatal("unknown build type (%s), please set to either 'release' or 'debug'" % _buildtype)
if _buildtype == 'debug':
d.setVar('MESON_BUILDTYPE', 'debugoptimized')
bb.plain("setting meson build type to debugoptimized")
}
addtask check_build_type before do_configure
I missed the fact that you were using a task.
You can probably call do_check_build_type() when setting
MESON_BUILDTYPE instead of using a task, e.g. something like this:
MESON_BUILDTYPE = "${@do_check_build_type(d.getVar('MESA_BUILD_TYPE'))}"


Re: variable and task/function timing

Richard Purdie
 

On Wed, 2019-12-11 at 10:39 -0500, Trevor Woerner wrote:
On Wed 2019-12-11 @ 11:06:44 AM, Nicolas Dechesne wrote:
+python do_check_build_type() {
+ _buildtype = d.getVar('MESA_BUILD_TYPE')
+ if _buildtype not in ['release', 'debug']:
+ bb.fatal("unknown build type (%s), please set to
either 'release' or 'debug'" % _buildtype)
+ if _buildtype == 'debug':
+ d.setVar('MESON_BUILDTYPE', 'debugoptimized')
+ bb.plain("setting meson build type to
debugoptimized")
+}
+addtask check_build_type before do_configure
+
EXTRA_OEMESON = " \
-Dshared-glapi=true \
-Dgallium-opencl=disabled \
Whether I move the above to before or after the "inherit meson..."
line makes no difference. Probably because the variable is being set
by a task (which, I assume, is too late to have any effect, which is
a large part of why I wrote this email: when do these tasks get
called with respect to how variable are being set by all the
different ways they're being set?)
Tasks run in isolation, if you change the datastore in a task it has no
way to get "seen" by other tasks. They're separate processes.

That is why the setVar in a task has no effect outside that task.

Cheers,

Richard

11021 - 11040 of 58675