[OE-core] [PATCH] linux-yocto-custom: Clarify defconfig usage

[Bruce Ashfield]

On Wed, Oct 3, 2012 at 8:10 AM, Andrea Adami <andrea.adami at gmail.com> wrote:
> On Wed, Oct 3, 2012 at 6:38 AM, Bruce Ashfield
> <bruce.ashfield at windriver.com> wrote:
>> On 12-10-03 12:36 AM, Darren Hart wrote:
>>>
>>> It is necessary to supply file://defconfig to the SRC_URI when using
>>> a defconfig (it is not implicitly understood as the commentary might
>>> currently suggest).
>>
>>
>> Acked-by: Bruce Ashfield <bruce.ashfield at windriver.com>
>>
>>
>>>
>>> Signed-off-by: Darren Hart<dvhart at linux.intel.com>
>>> CC: Bruce Ashfield<bruce.ashfield at windriver.com>
>>> ---
>>>   meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>> b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>> index 1f0b3a2..4115d2f 100644
>>> --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>> +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>> @@ -13,7 +13,8 @@
>>>   #
>>>   #   You must also provide a Linux kernel configuration. The most direct
>>>   #   method is to copy your .config to files/defconfig in your layer,
>>> -#   in the same directory as the bbappend.
>>> +#   in the same directory as the bbappend and add file://defconfig to
>>> +#   your SRC_URI.
>>>   #
>>>   #   To use the yocto kernel tooling to generate a BSP configuration
>>>   #   using modular configuration fragments, see the yocto-bsp and
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> Great, this example can be very useful to create custom kernel recipes.
>
> Just one thing, the comments on the top suggest to set
> #     COMPATIBLE_MACHINE_yourmachine = "yourmachine"
>
> but at the end there is
> COMPATIBLE_MACHINE = "(^$)"
>
> Now, the latter form is what I'm used to see.
>
> Which kind of advantages using COMPATIBLE_MACHINE_yourmachine ? In
> that way you don't mask the recipe for other machines...so I don't see
> the purpose and I think should be discouraged. Thus, I'd amend the
> example in the comment.

I wouldn't call it exactly masking with that syntax. Other machines
can still set
their compatibility explicitly with their own machine specific
override, which is
how linux-yocto + linux-yocto-bsp + meta-$semi have been put together for
quite some time.

The goal is to set a base which is incompatible with all machines, and then
suggest that you must have a machine or other layer that adds your
explicit compatibility (I know I'm stating the obvious) .. and using a machine
specific override to do that is one good way to be clear and avoid overly long
and complex series of |'d (is that a word?) machines that can cause append
problems in their own right.

So I'd think that an update to the comment that included COMPATIBLE_MACHINE
or COMPATIBLE_MACHINE_append would be a good addition, but I wouldn't
drop the existing text .. just augment it if we want.

Good comment though.

Cheers,

Bruce

>
> My 2 cents
>
> Andrea
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



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