From: "Peter Bergin" <peter@berginkonsult.se>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
openembedded-core@lists.openembedded.org
Cc: anuj.mittal@intel.com, otavio@ossystems.com.br
Subject: Re: [OE-core] [RFC][PATCH] libubootenv: exclude from world build if no u-boot config
Date: Thu, 8 Jul 2021 11:43:45 +0200 [thread overview]
Message-ID: <a9a36c96-c9e3-c665-28f7-ace236d06603@berginkonsult.se> (raw)
In-Reply-To: <54f75f5235de458ba76f53ed6ef77a98092b9da7.camel@linuxfoundation.org>
On 2021-07-08 09:07, Richard Purdie wrote:
> On Tue, 2021-07-06 at 17:55 +0200, Peter Bergin wrote:
>> 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 <peter@berginkonsult.se>
>> ---
>> 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
prev parent reply other threads:[~2021-07-08 9:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-06 15:55 [RFC][PATCH] libubootenv: exclude from world build if no u-boot config Peter Bergin
2021-07-08 6:16 ` Anuj Mittal
2021-07-08 7:07 ` Richard Purdie
2021-07-08 9:43 ` Peter Bergin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9a36c96-c9e3-c665-28f7-ace236d06603@berginkonsult.se \
--to=peter@berginkonsult.se \
--cc=anuj.mittal@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.