Background: Back in September, Richard made a commit to
linux-libc-headers.inc describing why one should not fork the
linux-libc-headers recipe:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=babbf7a46acaefd9b36031483cafce053f607e66
As a result I created a local bbclass for our layer
On Thu, Jan 16, 2014 at 8:58 AM, Peter Kjellerstedt
wrote:
> Background: Back in September, Richard made a commit to
> linux-libc-headers.inc describing why one should not fork the
> linux-libc-headers recipe:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=babbf7a46acaefd9b36031483c
Op 16 jan. 2014, om 14:58 heeft Peter Kjellerstedt
het volgende geschreven:
> Background: Back in September, Richard made a commit to
> linux-libc-headers.inc describing why one should not fork the
> linux-libc-headers recipe:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=bab
On Thu, 2014-01-16 at 14:58 +0100, Peter Kjellerstedt wrote:
> So, here I am now. I do not know who else use the
> do_make_scripts() function from module-base.bbclass and in what
> way, and whether restructuring the functionality into the new
> kernel-scripts.bbclass without maintaining backward
lass).
> > However, there is nothing besides module.bbclass in OE Core
> > and meta-oe that use the module-base.bbclass.
>
> Can't do_make_script run as an sstate post function?
I think that is exactly what the reverted change Bruce mentions
below did.
> regards,
>
> K
.. not so much (but I'm stating what we
all know).
So in the end, the question is the extra class "clutter" versus compatibility.
I lean towards the extra class with the compatibility maintained .. but I'm
not adamant about the issue :)
Cheers,
Bruce
>
>> Cheers,
>>
>> B
