On Wed, 9 Nov 2016 15:42:29 -0800 Andre McCurdy <[email protected]> wrote:
> On Wed, Nov 9, 2016 at 10:08 AM, Paul Barker <[email protected]> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
