Re: BB_STAMP_POLICY

[Detlef Vollmann <dv@vollmann.ch>]

Richard Purdie wrote:
> The correct solution from a bitbake/OE perspective is to have multiple
> providers, one for set of options combination and to switch between them
> using PREFERRED_PROVIDER.
I understand, and that's why I started that way.
But it starts to explode, and I have some uncomfortable feeling about
breaking changes going unnoticed...

> The biggest challenge you find when doing this is lots of recipes use
> ${PN} internally and by creating a new package you then need to hardcode
> that variable.
Another problem is the hardcoded name of packages inside recipes
(glibc-package.bbclass is a prominent example for that).

> Since thats the main barrier to doing this
I wouldn't say that's the main barrier.  It's annoying, but once
you know what to look for it's just some search and replace.

The biggest problem I see are silent breaks, because of changes in
some configuration files that are not tracked by dependency checking.

 > I'd propose trying to remove
> that obstacle. We could do this by having:
> 
> bitbake.conf:
> 
> PKGPN ?= "${PN}"
> 
> and then using PKGPN in recipes instead of PN. If you then create a
> glibc-some-extra-option you can just add a line which says:
> 
> PKGPN = "glibc"
> 
> and it should all work. This would also be useful for -sdk and -native
> recipes for example which currently have nastier workarounds for this
> problem.
> 
> Would this solve the problem?
It would make the the setup of the additional recipes easier, but
it doesn't solve the main problem of breaking changes.
For that maybe something in insane.bbclass could check and complain
about settings like EXTRA_OECONF_xyz in a conig file when
BB_STAMP_POLICY is set.

   Detlef