[oe] DISTRO override logic in angstrom.inc

[Paul Sokolovsky]

Hello,

On Mon, 18 Feb 2008 21:54:24 +0000
Richard Purdie <rpurdie at rpsys.net> wrote:

> On Mon, 2008-02-18 at 22:27 +0200, Paul Sokolovsky wrote:
> > On Mon, 18 Feb 2008 20:52:30 +0100
> > Michael 'Mickey' Lauer <mickey at vanille-media.de> wrote:
> > 
> > > Not having paid close attention to the "A case for user distro"
> > > thread, I was quite surprised when today the OpenMoko distro
> > > override no longer worked.
> > > 
> > > OpenMoko bases on angstrom and subsequently includes angstrom.inc
> > > which forcefully sets DISTRO = angstrom. I wonder whether this is
> > > a bit too violent against sharing files.
> > > 
> > > I had to 
> > > 
> > > -OVERRIDES = "local:${MACHINE}:${DISTRO}:angstrom:${TARGET_OS}:
> > > ${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
> > > +OVERRIDES = "local:${MACHINE}:openmoko:angstrom:${TARGET_OS}:
> > > ${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
> > > 
> > > to get the wanted behaviour back.
> > 
> > Hm, but that only shows that overriding DISTRO is indeed weird thing
> > which can lead to complex include file interactions. So, how it was
> > before is:
> > 
> > 1. openmoko.conf includes angstrom-2007-for-openmoko.inc which
> > indirectly includes angstrom.inc which overrides DISTRO.
> > 2. Then, openmoko.conf had DISTRO="openmoko" which looked like null
> > assignment, but actually re-set DISTRO after angstrom.inc's deeds.
> 
> This kind of justifies my concerns over changing this stuff as its
> subtle. 

You'd know my answer, right - somebody should... ;-) Living in fear of
changing that doesn't help either. I guess treating OVERRIDES as
something mystical was the reason why "DISTRO=" got into angstrom.inc in
the first place.

> It has highlighted that openmoko was running without
> "angstrom" in overrides at all though 

Hm, why? "-" change from Mickey shows there was literal "angstrom" in
there. So, it was "openmoko:angstrom" before, became
"angstrom:angstrom" after my change, and now set back in explicit way.
I assume that OVERRIDES are processed in order, so if there're both
openmoko and angstrom override, first will have priority, otherwise
angstrom's will be picked up, and I guess that's desired behavior.

> which if its truly angstrom
> derived might have caused problems. Alternatively, Mickey's change
> isn't 100% equivalent to what was there before and I'd suggest Mickey
> considers it carefully.
> 
> > I believe the OVERRIDES update above is the correct and reliable
> > solution to this issue, and would like to propose that we finished
> > with this DISTRO override cleanup:
> > 
> > 1. Treat DISTRO as the input-only parameter from user, and thus ban
> > assignments to it.
> > 2. Make Angstrom to use OVERRIDES like above.
> > 
> > I don't know if Angstrom relies somewhere else on DISTRO to be
> > overriden, but that can, and should be fixed too (usage in OVERRIDES
> > apparently should be the most heavy assumption).
> > 
> > I also think that using literal values like "openmoko" and
> > "angstrom" is the right way, though for completeness, here's
> > version with extra indirection. In bitbake.conf:
> > 
> > DISTRO_OVERRIDE = ${DISTRO}
> > OVERRIDES =
> > "local:${MACHINE}:${DISTRO_OVERRIDES}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
> >
> > Then distros which need that can use DISTRO_OVERRIDE :=
> > 
> > Again, IMHO that just complicates the matter.
> 
> I'm voting in favour of:
> 
> DISTRO_OVERRIDES ?= ${DISTRO}
> OVERRIDES
> ="local:${MACHINE}:${DISTRO_OVERRIDES}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
> 
> and then angstrom sets:
> 
> DISTRO_OVERRIDES = "angstrom"
> 
> and openmoko sets:
> 
> DISTRO_OVERRIDES = "openmoko:angstrom"
> 
> Note there is no longer any use of := and that the main list of
> overrides is only written in one place rather than spread out per
> distro which could cause maintenance problems in the future.

You know better. If such use with ":" inside is acceptable, and it's
really DISTRO_OVERRIDE*S*, so the meaning of it is not "a var where
distro may put something to use instead of its name in OVERRIDES", but
instead "var which holds values on which distro wants to override, in
addition to standard overrides", then it's even better ;-).


> 
> Cheers,
> 
> Richard
> 

[]


-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com