On Tue, Jul 26, 2022 at 07:35:21AM +0200, Alexander Kanavin wrote:
> On Tue, 26 Jul 2022 at 06:09, Patrick Williams <patrick@stwcx.xyz> wrote:
> > There are some more complex examples, but one easy example is a recipe
> > which had `file://${MACHINE}/eeprom.h` in its SRC_URI[1].  Any machine
> > which didn't provide this file, even if it never intended to use the
> > recipe, now fails when we picked up this change.
> 
> This is not how machine-specific versions of the same file are
> supposed to be listed. Just use `file://eeprom.h`, and bitbake will
> look for it in subdirectories that include $MACHINE, and if not found
> there, a default version will be picked (which you can make bogus, so
> builds will fail at recipe build stage instead of parsing stage).
> 
> Example:
> https://git.yoctoproject.org/poky/tree/meta/recipes-graphics/xorg-xserver/xserver-xf86-config?h=master-next

I agree.  The person who originally wrote the recipe didn't know about
the automatic addition of overrides with the FILESEXTRAPATHS.  As I
wrote this was just one easy example.  I fixed this one to both use the
override implicitly (as you also suggested) and put a default 'eeprom.h'
with a `#error`[1].

A seriously more complex example we have is that we have our own u-boot
recipes and used the same `u-boot-foo.inc` file names as are present in
`meta/`.  It happens that the recipes in `meta/recipes-bsp/u-boot` end
up, even though we'd never use them, using our `u-boot-foo.inc` files
and ending up with totally bogus SRC_URIs in the parsing phase (and
thus failing).  Essentially, whenever there is a new version of u-boot
in `meta` we're going to end up having to make some bogus empty
files[2].

> 
> > I know we've been ignoring the warning(s) for a while on these kinds of
> > failures, so it is our own fault, but it is kind of annoying the new
> > behavior.  We now have to make sure every recipe not only parses validly
> > on all machine configs but it also has to have fully populated SRC_URIs
> > even when the recipe is never used on that machine config.
> >
> > 1. https://github.com/facebook/openbmc/blob/f0d9511ad2fbd563a6b793093cdac557c5ef2a89/meta-facebook/recipes-utils/mac-util/mac-util_0.1.bb#L12
> 
> Look, this is bleeding edge. And bleeding edge sometimes bleeds and
> breaks your builds. You signed up for it; if you don't like it there,
> use stable branches, or use controlled transitions to milestone tags.

I agree we signed up for the bleeding edge, partially to be more aware
of changes like this.  Hopefully this wasn't worded too poorly, but I am
not complaining that "things are currently broken for me".  I was trying
to raise awareness that this change isn't as pleasant to downstream layer
maintainers as it might seem on the surface.  If there is an improvement
or revert, great; if there isn't, we'll deal with it.

1. https://github.com/facebook/openbmc/commit/c4e6ffacb73a567c83458f6a1b7e5bb0a032b770
2. https://github.com/facebook/openbmc/tree/c4e6ffacb73a567c83458f6a1b7e5bb0a032b770/meta-aspeed/recipes-bsp/u-boot/files/openbmc-fb
-- 
Patrick Williams