It isn't every day I propose new syntax and the bar for doing so is high but I think we have a good case for making his change.
I've put together a proof of concept patch here: https://lists.openembedded.org/g/bitbake-devel/message/15738 The idea is to add syntax for: inherit_deferred ${SOME_VARIABLE} which would handle the inherit at the end of parsing rather than immediately. The reason is that currently people don't realise that in order for bitbake to parse that, it has to immediately expand the variable at that point in parsing. This means: SOME_VARIABLE = "a" inherit ${SOME_VARIABLE} SOME_VARIABLE = "b" will inherit class a, whilst with inherit_deferred, it would inherit class b. SOME_VARIABLE = "a" inherit_deferred ${SOME_VARIABLE} SOME_VARIABLE += "b" would inherit a and b. When the inherit is conditional on a variable like PACKAGECONFIG, this starts to make a lot more sense to users as you can change PACKAGECONFIG in a bbappend and the behaviour the user expects will occur. It isn't as simple to implement as you'd first think as we require native/nativesdk classes to be last and a deferred class can add further deferred inherits so we have to be very careful about ordering. I did run some tests against OE-Core and whilst I ran into some horrible variable ordering issues (TARGET_HOST_TASK for example), I have patches in master-next (commit messages and cleanup still pending) which do allow all our current tests to pass. If the warning in the patch is enabled, it will show warnings in meta- oe, meta-agl and meta-mingw but nothing which can't be fixed relatively easily. Given that I think I'd be in favour of a fairly fast removal of support for non-deferred conditional inherits, probably landing quickly so we can include in the next release. Just to be clear, I'm in favour of this new syntax because: a) it is pretty simple b) it should be clear to users what it is doing c) it solves a common real world usability issue people run into d) we can clearly detect and error for the corner case we want to deprecate/remove e) we can give the user a specific error message about how to fix it I have wondered about a INHERIT_DEFERRED variable instead. There are pros and cons to it since it would allow easier editing of the classes (e.g. using append, += and remove) but it would also potentially add confusion since INHERIT only works in configuration files and is actually a deferred inherit for them. It also still leaves an "arms race" since you couldn't undo a remove. Using the syntax proposed above doesn't preclude allowing editing of the list via a variable at a later date if we did want to go that route. It has the benefit of matching the current inherit people expect in recipes/classes. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1906): https://lists.openembedded.org/g/openembedded-architecture/message/1906 Mute This Topic: https://lists.openembedded.org/mt/103493127/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
