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

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

On Tue, Nov 19, 2013 at 5:42 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote:
>>
>> Exactly. And I had windriver bug with the same symptoms as yours. It
>> was a package
>> that built its own modules, and hence never called this either.
>>
>> > and my recipes did override module_do_compile task but not do_compile like below
>> >
>> > module_do_compile() {
>> >         oe_runmake
>> > }
>> >
>> > so, is comment wrong there should it say module_do_compile instead ?
>> >
>> > will it work with sstate always ?
>> >
>> > it will be OK to revert it if thats the case.
>>
>> I'll come up with something that works in all cases. The sstate fix is
>> better from the point
>> of view that it is transparent to the recipes, and they don't need to
>> do anything special
>> for the support.
>>
>> So my proposal is this:
>>
>>  - fix the new bug at hand by making the sstate change depend on the
>> toolchain (I agree
>>    that patching the scripts to not reference the target toolchain
>> isn't a good idea since not
>>   all kernels get the rix).
>
> Can we please not do this? Adding in toolchain dependencies into the
> sstate code whilst possible, is going to massively complicate the
> dependency chains and is a last possible resort. I bought that argument
> in the useradd case since there are horrible issues there. We don't have
> that issue here.
>

Works for me. I just wonder if there's another way to handle things
more gracefully ? i.e. somehow check if the toolchain isn't available
and warn, otherwise continue making the scripts ?

> In kernel terms, its safer/easier to hack the kernel makefiles than
> expecting sstate to work well with dependencies like that embedded in
> it.

It is pretty simple to make the change. Just making it available everywhere
is the trick.

>
>>  - remove the modules-base.bbclass scripts recreation, so we only have
>> one scripts
>>    restore in the tree.
>>
>> Alternatively, recipes need to be fixed to call the
>> modules-base.bbclass routine to restore
>> scripts, and I think it is obvious that won't work in all cases.
>
> Which cases won't that work in?
>
> As far as I'm concerned, people using module-base are taking a loaded
> gun and are expected to use it safely (which means calling
> do_make_scripts somehow). People wanting a safer ride can use module
> which adds the appropriate task for them.

I've got people not using any of the above .. yes, I know they are evil
too :)

>
> The comments in the bbclass files do need fixing but that is trivial to
> sort out.
>
>> I'll wait for comments/concensus before sending a new patch (which
>> needs to be tested
>> on all the cases), but in the meantime, the patches to the list to fix
>> the sstate solution are good to be applied.
>
> I will respectfully disagree ;-).

No patch from me for this then. That's why i waited, I figured it wouldn't
be immediate agreement.

Bruce

>
> Cheers,
>
> Richard
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"