[OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot

[Phil Blundell]

On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote:
> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
> > When building against the sysroot, out of tree modules can require modpost
> > and other utilities normally found in the kernel's scripts directory. For
> > the kernel source in the staging dir, these scripts have been removed to
> > avoid mixing archiectures when packaging kernel-dev (among other things).
> > 
> > Rather than further complicate the kernel's install rule, or its packaging,
> > we can restore the scripts by building them in the kernel staging directory
> > after the sstate is installed, making them available to packages that need them.
> > 
> > Signed-off-by: Bruce Ashfield <bruce.ashfield at windriver.com>
> > ---
> >  meta/classes/kernel.bbclass | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index 4acfb7e..d5fa801 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -292,6 +292,17 @@ kernel_do_install() {
> >  }
> >  do_install[prefuncs] += "package_get_auto_pr"
> >  
> > +
> > +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
> > +kernelscripts_sstate_postinst () {
> > +	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
> > +		( 
> > +		  cd ${STAGING_KERNEL_DIR}
> > +		  oe_runmake scripts
> > +		)
> > +	fi
> > +}
> > +
> >  sysroot_stage_all_append() {
> >  	sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
> >  }
> 
> This sstate_postinst fails for me when the compiler isn't already present
> in the sysroot.
> 
> Also, I notice that the environment and parameters passed to oe_runmake are
> not the same as those used by kernel_do_compile etc.

Also note that module.bbclass already does "make scripts" before
do_compile() so out-of-tree modules should already have access to all
the files that they need.  

If we're going to make a policy decision that the kernel is responsible
for making scripts then I guess that's fine (modulo the implementation
problems that Mike describes) but in that case the code in
module{-base}.bbclass is redundant and ought to be removed.

p.