[OE-core] [PATCH] kernel.bbclass: Allow ${S} to be overridden

[Paul Barker]

On Wed, 9 Nov 2016 15:42:29 -0800
Andre McCurdy <armccurdy at gmail.com> wrote:

> On Wed, Nov 9, 2016 at 10:08 AM, Paul Barker <paul at paulbarker.me.uk> wrote:
> >
> > The reason for this patch is that I'm using a tarball for the kernel
> > sources in the new meta-arduino layer. That tarball doesn't get
> > extracted to ${STAGING_KERNEL_DIR} and so it needs to be copied over to
> > there. Looking at kernel.bbclass, it looks like the logic to do this is
> > present:
> >
> >
> >     # Old style kernels may set ${S} = ${WORKDIR}/git for example
> >     # We need to move these over to STAGING_KERNEL_DIR. We can't just
> >     # create the symlink in advance as the git fetcher can't cope with
> >     # the symlink.
> >     do_unpack[cleandirs] += " ${S} ${STAGING_KERNEL_DIR} ${B} ${STAGING_KERNEL_BUILDDIR}"
> >     do_clean[cleandirs] += " ${S} ${STAGING_KERNEL_DIR} ${B} ${STAGING_KERNEL_BUILDDIR}"
> >     base_do_unpack_append () {
> >         s = d.getVar("S", True)
> >         if s[-1] == '/':
> >             # drop trailing slash, so that os.symlink(kernsrc, s) doesn't use s as directory name and fail
> >             s=s[:-1]
> >         kernsrc = d.getVar("STAGING_KERNEL_DIR", True)
> >         if s != kernsrc:
> >             bb.utils.mkdirhier(kernsrc)
> >             bb.utils.remove(kernsrc, recurse=True)
> >             if d.getVar("EXTERNALSRC", True):
> >                 # With EXTERNALSRC S will not be wiped so we can symlink to it
> >                 os.symlink(s, kernsrc)
> >             else:
> >                 import shutil
> >                 shutil.move(s, kernsrc)
> >                 os.symlink(kernsrc, s)
> >     }
> >
> > The problem is we can't set S to anything unless we can override it.
> >
> > I've now looked into this futher and it seems to be working for some
> > kernel recipes but not others. The issue may be that we have an
> > assignment for S in bitbake.conf:
> >
> >     S = "${WORKDIR}/${BP}"
> >
> > That's obviously overriding the 'S ?= ...' assignment when my patch is
> > applied where S isn't also explicitly assigned in the recipe, some
> > other class or include file.
> >
> > I'm not sure on how precedence is determined if a variable is assigned
> > using '=' multiple times.
> >
> > I'll have another look into it and see where I get. I have a workaround
> > in place for the meta-arduino layer for now so it doesn't need an
> > urgent fix.
> >
> > However, if it turns out we can't reliably override S in a kernel recipe
> > then should we still have that comment and base_do_unpack_append() in
> > kernel.bbclass?
> 
> The solution I use (learned the hard way) is to ensure that "S = ..."
> comes after "inherit kernel" in the kernel recipe.
> 

Ok, yea, this works for me.

Is this expected? S is set to ${STAGING_KERNEL_DIR} at the start of
kernel.bbclass. The base_do_unpack_append() function is defined later
in kernel.bbclass. If S is set to ${WORKDIR}/${BP} only after
kernel.bbclass is inherited, then that's after base_do_unpack_append()
has been parsed.

I've re-read the bitbake user manual [1] but I can't clearly understand
why this works. Is it to do with when the _append is applied?

Is there any way we can make this more obvious or is this just the
nature of bitbake?

[1]: http://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#basic-syntax