On 13-09-01 8:32 AM, Peter A. Bigot wrote:
Thanks for the additional information. My entire expectation of how
linux-yocto metadata worked turns out to be wrong, but you've managed to
clear it up for me.
What I really wanted from linux-yocto was a way to isolate documented
kernel configuration f
Thanks for the additional information. My entire expectation of how
linux-yocto metadata worked turns out to be wrong, but you've managed to
clear it up for me.
What I really wanted from linux-yocto was a way to isolate documented
kernel configuration fragments to share configuration data amon
On 13-08-31 12:07 PM, Peter A. Bigot wrote:
Thanks; I'm starting to understand. It makes more sense to know this
all pre-dates Yocto (and maybe its use within bitbake/OE).
heh. It first existed in 2006, in one form or another. The Yocto mapping
is the latest incarnation of the tools. So it has
Thanks; I'm starting to understand. It makes more sense to know this
all pre-dates Yocto (and maybe its use within bitbake/OE).
I've generated a lot of text below, but I think the priority for 1.5
should be to enhance the documention of the current approach, rather
than try to address any of
I want the ability to have a BSP layer linux-yocto_3.10.bbappend which
supports a new machine by providing a BSP scc file and some BSP-specific
overrides in recipe space that re-use and where necessary override
features that exist in the standard meta hierarchy. There is some
previous discussi
On 13-08-30 03:33 PM, Peter A. Bigot wrote:
I want the ability to have a BSP layer linux-yocto_3.10.bbappend which
supports a new machine by providing a BSP scc file and some BSP-specific
overrides in recipe space that re-use and where necessary override
features that exist in the standard meta h
