On Wed, 9 Nov 2016 08:09:09 -0500 Bruce Ashfield <[email protected]> wrote:
> On Wed, Nov 9, 2016 at 5:04 AM, Burton, Ross <[email protected]> wrote: > > > > > On 9 November 2016 at 02:23, Bruce Ashfield <[email protected]> > > wrote: > > > >> I can ack this patch, since no defaults change .. there's no risk to > >> existing users. > >> > > > > Saying that of course doomed the patch: > > > > interesting. > > Paul: obviously you were building with this in place, and my local test did > work here > as well .. so any idea to the difference ? > > Let me know if you want any help looking into it. > > Cheers, > > Bruce > 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? Thanks, Paul -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
