On Wed, Oct 3, 2012 at 8:10 AM, Andrea Adami <[email protected]> wrote: > On Wed, Oct 3, 2012 at 6:38 AM, Bruce Ashfield > <[email protected]> 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 <[email protected]> >> >> >>> >>> Signed-off-by: Darren Hart<[email protected]> >>> CC: Bruce Ashfield<[email protected]> >>> --- >>> 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 >> [email protected] >> 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 > [email protected] > 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" _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
