Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 13-10-07 05:58 AM, Richard Purdie wrote:
> On Mon, 2013-10-07 at 01:02 -0400, Bruce Ashfield wrote:
>> On 13-10-04 3:46 AM, Richard Purdie wrote:
>>> On Thu, 2013-10-03 at 20:02 -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).
>>>
>>> Its also to avoid mixing architectures when packaging the sstate for
>>> do_populate_sysroot. The sstate for that task is now native arch
>>> specific after this patch but its task hash is not. Even if we made it
>>> native specific, that means the kernel would rebuild entirely if you
>>> switch 32 bit to 64 bit native machine. We therefore cannot merge this
>>> patch as is.
>>>
>>> Instead do something like:
>>>
>>>
>>> SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst"
>>>
>>> kernelheaders_sstate_postinst () {
>>> 	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
>>> 	then
>>> 		( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};
>>> 		  oe_runmake scripts
>>> 		)
>>> 	fi
>>> }
>>>
>>> This will rerun the oe_runmake scripts each time the sstate package is
>>> installed. It slows down the use of sstate but should be correct whether
>>> the build machine is 32 or 64 bit.
>>
>> I poked with this a bit over the weekend, and never did get the right
>> results.
>>
>> I can make the scripts trigger, but since the sysroot population appears
>> to already be done, but build scripts don't actually make it into the
>> sysroot for use during module builds.
>>
>> I tried a few variants of the below, all trying to get the actual
>> tmp/sysroots/<machine> to have the scripts, with no luck. Dumping the
>> available variables didn't get me anything really promising either.
>>
>> I'll have another look in the morning, since I'm sure it is just me not
>> understanding the ordering of things .. but any pointers would of course
>> be appreciated.
>>
>> Cheers,
>>
>> Bruce
>>
>> STATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
>> kernelscripts_sstate_postinst () {
>>           if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o
>> "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
>>                   sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
>> ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
>>                   oe_runmake -C ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} scripts
>> 	fi
>> }
>>
>
> Ah, I had it slightly wrong. Try:
>
> kernelheaders_sstate_postinst () {
>   	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
>   	then
>   		( cd ${KERNEL_SRC_PATH};
>   		  oe_runmake scripts
>   		)
>   	fi
>   }
>
> since the files are actually installed at this point, therefore we
> operate on the final location.

That's the kicker, I can't get the right variable to find the final
location, KERNEL_SRC_PATH is set to /usr/src/kernel, so we can't operate
on it directly. When things were runing in the sysroot_append, the
kernel src was staged, and then operated on, then it makes it into the
sysroot. Here, we could operate on the STAGING_KERNEL, which is in the
sysroot, but stripped of the scripts. Perhaps that is the answer, but
I need to confirm that scripts installed in that location would be
available to the out of tree module builds that are looking for modpost
and friends.

>
> The risk here is that when we uninstall the sstate package, we don't
> track the generated files. We can probably live with that for now.

Agreed.

>
> What we really needs is a preinst but the one we have is really a
> preunpack :/.
>
> Ultimately, I think we need to rename the preinst to preunpack and add a
> real preinst...

I'll keep digging.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>