[meta-ti] Use of MACHINE_KERNEL_PR in meta-ti recipes

[Denys Dmytriyenko]

On Sat, Dec 03, 2011 at 03:26:32PM -0800, Khem Raj wrote:
> On Sat, Dec 3, 2011 at 3:18 PM, Denys Dmytriyenko <denis at denix.org> wrote:
> > On Sat, Dec 03, 2011 at 01:42:30PM -0800, Khem Raj wrote:
> >> On Sat, Dec 3, 2011 at 1:13 PM, Khem Raj <raj.khem at gmail.com> wrote:
> >> > Hi
> >> >
> >> > I am seeing this kind of error all over in meta-ti recipes
> >> >
> >> >
> >> > ERROR: Unable to analyse format of PR variable: ${MACHINE_KERNEL_PR}e
> >> > ERROR: Unable to parse
> >> > /home/kraj/work/angstrom/sources/meta-ti/recipes-ti/local-power-manager/ti-local-power-manager_1.24.02.09.bb
> >> >
> >> > Problem seems to be that these recipes are not getting
> >> > MACHINE_KERNEL_PR from anywhere but they are using it
> >> > and its not a standard variable in bitbake.conf either. I have
> >> > manually patched recipes-ti/includes/ti-staging.inc
> >> > to contain MACHINE_KERNEL_PR ?= "r0"
> >> >
> >> > and patched few recipes which did not include this include to have the
> >> > definition in them
> >> >
> >> > I don't know if this is the right way to fix it but this has got me
> >> > over the parsing problems
> >>
> >> btw. I am using qemuarm machine with angstrom distro on top of oe-core
> >> and qemuarm conf does not define MACHINE_KERNEL_PR either
> >
> > Ah, that explains it. Why do you need meta-ti layer with qemuarm? Is there a
> > specific recipe you need from it or you are just trying all layers in default
> > setup?
> 
> I am trying angstrom defaults. I think a COMPATIBLE_MACHINE is nice to contain
> the recipes for your machine layer only so it can be used in default
> angstrom setup
> for non TI machines. Since I build TI and non TI machines in same
> tmpdir I dont want
> to keep editing my layers.txt every time I use a different machine

Actually, we'd like to ease off of COMPATIBLE_MACHINE use in our recipes to 
make them more generic wherever possible.

I understand that MACHINE_KERNEL_PR is not entirely standard variable and 
probably we should try to find a better alternative for its purpose...

-- 
Denys