Re: [bitbake-devel][PATCH] bb: Add prefuncs and postfuncs ordering
Richard Purdie <[email protected]> Sun, 28 Jun 2026 11:11:05 +0100
| Newsgroups | org.openembedded.lists.bitbake-devel |
|---|---|
| Message-ID | <672671c32a5845e923ef216fd1a15483328def3c.camel@linuxfoundation.org> |
On Sun, 2026-06-28 at 08:29 +0100, Richard Purdie via lists.openembedded.or= g wrote: > On Fri, 2026-06-26 at 11:00 -0600, Joshua Watt via lists.openembedded.org= wrote: > > 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 th= e > > 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 relativ= e > > order (this means that existing behavior is preserved in the absence of > > any ordering information). > >=20 > > Signed-off-by: Joshua Watt <[email protected]> >=20 > 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. >=20 > 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. >=20 > 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. >=20 > You could even define a filter function for the variable which could > reorder things with a custom order function. >=20 > 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. >=20 > 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. I couldn't help thinking about this more, the syntax I was wondering about was something along the lines of: do_xxx[postfuncs] +=3D "functionC[after-functionB,after-functionA,before-fu= nctionD]" which is horrible, but at least explicit. Cheers, Richard