Re: [bitbake-devel][PATCH] bb: Add prefuncs and postfuncs ordering

On Fri, 2026-06-26 at 11:00 -0600, Joshua Watt via lists.openembedded.org w=
rote:
> Adds the ability for functions specified in prefuncs and postfuncs to
> specify the order in which they must execute. This allows specific
> functions to indicate that they must run first or last (or second,
> second to last, etc.) without needing all places in the code that
> manipulate the function list to have to agree on how to order them
> (a good example of this is sstate.bbclass and buildhistory.bbclass).
>=20
> Ordering is done similar to how python list indices work; 0 is always
> sorted first, 1 is second, -2 is second to last, -1 is last, etc. In the
> event of functions having duplicate values, they are grouped together,
> but keep their same relative ordering. If one or more functions do not
> have an order assigned, they executed between the positive order
> functions and the negative order functions, and keep their same relative
> order (this means that existing behavior is preserved in the absence of
> any ordering information).
>=20
> Signed-off-by: Joshua Watt <[email protected]>

I've wondered about something like this for a long time, the trouble is
it does not scale well and I've always concluded it wouldn't really
help overall and solve the real problem.

It solves an immediate issue of making one thing run first, or last. If
a second comes along, it can just about handle that. The trouble is
when you have three or more and they all want to be "last", or "first",
you can't define that in the metadata. This just gets worse when you
think of independent layers trying to pick numeric values. This is
already a pain with layer priorities and I wish we'd never used
numbers.

You can already get some idea of ordering just by the +=3D and =3D+
operations ordering the data, or reordering the variable contents using
anon python.

You could even define a filter function for the variable which could
reorder things with a custom order function.

So I'm probably against adding this level of complexity when we already
have enough of it and it doesn't fully solve the issue anyway.

If we did something, I'd probably look in the direction of "after" and
"before" operations like tasks, trying to avoid some of the issues we
have there.

Cheers,

Richard