Re: bitbake.conf: add lz4c to HOSTTOOLS_NONFATAL

[Justin Bronder <jsbronder@cold-front.org>]

On 10/12/24 21:53 +0000, Richard Purdie wrote:
> On Tue, 2024-12-10 at 10:10 -0500, Justin Bronder via lists.openembedded.org wrote:
> > Commit fe167e082cbde1c6d186ecdda531abef610ac2ac switched to requiring
> > lz4 instead of lz4c which allows us to support distros dropping lz4c.
> > However, it's only in the 6.13 kernel that CONFIG_KERNEL_LZ4 makes the
> > switch from lz4c to lz4.� So we should continue to link lz4c if it's
> > available to support older kernels.
> > 
> > Signed-off-by: Justin Bronder <jsbronder@cold-front.org>
> > ---
> > �meta/conf/bitbake.conf | 3 +++
> > �1 file changed, 3 insertions(+)
> > 
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index 1d2c2e0022..c7927d19a0 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -553,6 +553,9 @@ HOSTTOOLS_NONFATAL += "gsutil"
> > �# Link to git-lfs if present
> > �HOSTTOOLS_NONFATAL += "git-lfs"
> > �
> > +# Link to lz4c if present, used by linux <6.13 with CONFIG_KERNEL_LZ4
> > +HOSTTOOLS_NONFATAL += "lz4c"
> > +
> > �CCACHE ??= ""
> > �
> > �TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
> > 
> 
> The YP TSC chatted a bit about this. Personally, I'm a bit nervous as
> this could make the builds a bit non-deterministic and allow the builds
> to fail well into the build. We try to do that "up front" if and where
> we can to make developers lives easier. This becomes more likely as
> distros drop lz4c and releases age, i.e. we'll hit problems years down
> the line.
> 
> I did have an idea for another potential solution which would be to put
> a lz4c wrapper in the scripts/native-intercept directory which tweaks
> the parameters and calls lz4.�Could I convince someone to see if that
> would work?

That works for the kernel build if I put the wrapper in scripts/.  But it
doesn't if the wrapper is in scripts/native-intercept as that's only added to
the PATH if native.bbclass is inherited.

Is adding a wrapper in script/ acceptable?  I see we already have one for git.

-- 
Justin Bronder