[RFC][PATCH] libubootenv: exclude from world build if no u-boot config

As a fix for failing the world build for targets not using u-boot
as boot loader libubootenv is excluded from world builds if
both UBOOT_MACHINE and UBOOT_CONFIG variables are empty.

Signed-off-by: Peter Bergin <redacted>
---
 meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb b/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
index 306296922c..6774290ea5 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb

@@ -28,3 +28,6 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 RRECOMMENDS_${PN}-bin_append_class-target = " u-boot-default-env"
 
 BBCLASSEXTEND = "native"
+
+# Exclude this package from world build if there is no config for u-boot
+EXCLUDE_FROM_WORLD = "${@'1' if not d.getVar('UBOOT_MACHINE') and not (d.getVar('UBOOT_CONFIG') or '').split() else '0'}"

-- 
2.25.1

On Tue, 2021-07-06 at 17:55 +0200, Peter Bergin wrote:

This looks good to me. This recipe was being skipped in world builds
for such targets anyway before we removed the uboot-config inherit.

Thanks,

Anuj

On Tue, 2021-07-06 at 17:55 +0200, Peter Bergin wrote:

To be honest I'm still struggling to understand the problem here.
(I'm also not sure we need the split() above)

You previously said "If you just want to build libubootenv you should be 
able to do it for any machine, with or without u-boot support as there is 
no build dependency between libubootenv and u-boot." which does make sense 
to me but the above doesn't seem to be much better than the original
inherit?

Perhaps we should be doing something like:

python () {
    if d.getVar('UBOOT_MACHINE') or d.getVar('UBOOT_CONFIG'):
        d.setVar('RRECOMMENDS_${PN}-bin_append_class-target', " u-boot-default-env")
}

since the recipe is marked as machine specific (which I worry about in 
itself).

Cheers,

Richard

On 2021-07-08 09:07, Richard Purdie wrote:

On Tue, 2021-07-06 at 17:55 +0200, Peter Bergin wrote:

quoted

As a fix for failing the world build for targets not using u-boot
as boot loader libubootenv is excluded from world builds if
both UBOOT_MACHINE and UBOOT_CONFIG variables are empty.

Signed-off-by: Peter Bergin <redacted>
---
  meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb b/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
index 306296922c..6774290ea5 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb

@@ -28,3 +28,6 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
  RRECOMMENDS_${PN}-bin_append_class-target = " u-boot-default-env"
  



  BBCLASSEXTEND = "native"
+
+# Exclude this package from world build if there is no config for u-boot
+EXCLUDE_FROM_WORLD = "${@'1' if not d.getVar('UBOOT_MACHINE') and not (d.getVar('UBOOT_CONFIG') or '').split() else '0'}"

To be honest I'm still struggling to understand the problem here.
(I'm also not sure we need the split() above)

I am also trying to understand the root of this and relate to other 
packages and dependencies in oe-core. Haven't found anything similar 
yet. The closest but not really related constructions is for 
'RDEPENDS_${PN} = "kernel-module-*"'  that (as far as I understand) 
ignored in build process and assumed provided. Otherwise I guess 
constructions similar to this are handled with COMPATIBLE_MACHINE but 
this is not related to MACHINE but to bootloader and we don't have a 
config for that.

You previously said "If you just want to build libubootenv you should be
able to do it for any machine, with or without u-boot support as there is
no build dependency between libubootenv and u-boot." which does make sense
to me but the above doesn't seem to be much better than the original
inherit?

llibubootenv can be built for all targets independent of bootloader. If 
libubootenv should be useful on target it should have configuration 
files in filesystem which are produced by u-boot as the source of 
information is there. So for me the general question is how we handle 
the case where package A needs (a config file from) package B to work 
properly on target but package B is not possible to build for this 
configuration?

Agree that it is possibly small improvement with this and still a 
workaround (as inherit uboot-config was). The improvement for 
meta-freescale is to avoid another workaround for this. In 
meta-freescale the variables UBOOT_MACHINE and UBOOT_CONFIG is in some 
cases set per recipe as configuration names for one machine differs 
between forks of u-boot.

Perhaps we should be doing something like:

python () {
     if d.getVar('UBOOT_MACHINE') or d.getVar('UBOOT_CONFIG'):
         d.setVar('RRECOMMENDS_${PN}-bin_append_class-target', " u-boot-default-env")
}

since the recipe is marked as machine specific (which I worry about in
itself).

The reason for machine specific setting of this package from commit 
(02d55cd35aa) message:

     "...Also add u-boot-default-env to RRECOMMENDS since
     /etc/u-boot-initial-env is being referred in libubootenv source, and
     turns libubootenv's PACKAGE_ARCH to be MACHINE_ARCH since
     u-boot-default-env is a machine-arch package."

So it turns out we make the recipe of libubootenv machine specific 
because we need a config file from another machine specific recipe.

The files /etc/fw_env.config and/etc/u-boot-initial-env is referenced in 
libubbotenv as the default paths to configuration. The programs tries to 
read and parse those files and if not found the programs exit out with 
error code and a clear message to the user. I agree with Otavios comment 
in the other mail thread that RDEPENDS is a too strong dependency 
between libubootenv-bin and u-boot-default-env.

This is probably a small issue and I'm a bit unsure how much more effort 
to spend on this? We should solve the issue with failing world build for 
'non-u-boot' configs caused by my initial revert. Is the way forward to 
make a conditional RDEPENDS as suggested? To keep it simple I would 
suggest to either:

1) removing RDEPENDS
2) change RDEPENDS->RSUGGESTS which seems to fix the build issue

In both cases above I think we can make libubootenv non-machine specific 
again. What do you think?

Best regards,

/Peter