On Tue, Dec 7, 2021 at 4:02 PM Richard Purdie <[email protected]> wrote: > > On Tue, 2021-12-07 at 11:09 -0800, Andre McCurdy wrote: > > On Tue, Dec 7, 2021 at 9:58 AM Richard Purdie <[email protected]> wrote: > > > > > > On Tue, 2021-12-07 at 17:53 +0000, Ross Burton wrote: > > > > On Tue, 7 Dec 2021 at 17:15, Konrad Weihmann <[email protected]> > > > > wrote: > > > > > TBF > > > > > > > > > > the correct fix would be > > > > > > > > > > magic.bbclass > > > > > --- > > > > > DEPENDS:append = " magic-dependency" > > > > > --- > > > > > > > > > > but unfortunately sometimes this is out of our control (as we don't > > > > > want > > > > > to have bbclassappends for totally valid reasons) > > > > > > > > > > Thoughts? > > > > > > > > Personally, I'd say that's the correct fix, and any class that > > > > DEPENDS= is just broken. Recipes should be able to do DEPENDS= because > > > > that's convenient, and classes should use DEPENDS:append. > > > > > > This is complicated by the issue that such appends are near impossible to > > > override, so you end up with the conditional bits in > > > autotools/base.bbclass > > > adding variables to set to stop the behaviour. Classes should be a > > > starting > > > point for things, not a hard requirement the recipe can't override. > > > > If the goal is to let the recipe undo changes made by a .bbclass then > > one easy solution is indirection. The class can use: > > > > MAGIC_DEPENDS ?= "foo" > > DEPENDS:append = " ${MAGIC_DEPENDS}" > > > > Recipes can then override MAGIC_DEPENDS as required. > > That does still feel like we're admitting our syntax is broken though :( > > > > I actually much prefer += in recipes for that reason but as you say, > > > people like > > > to use = and then the problem continues. This kind of issue is one of the > > > things > > > we really need to solve as a project and is probably the most pressing > > > syntax > > > problem. See the PACKAGECONFIG discussion/dilemma too. > > > > I've seen the discussion. No real explanation of what the dilemma is > > though... > > By that you mean I didn't expand on the other thread? Sadly I haven't had the > time, no. I didn't prioritise it as you made it clear you don't intend to send > patches to OE again. You have given a lot of good feedback on changes and > have a > lot of good knowledge so that is a shame btw. > > Things have been discussed in the past, I doubt I can dig out a precise > pointer > to those discussions unfortunately as I'm struggling to find anything (I did > spend a while trying). I can try to summarise how I've seen the different > sides > to this presented. > > It basically comes down to users expecting to be able to do several different > things and different syntax works better for different use cases. > > In general a user may want to a) change a single item in a config or b) > override > the config entirely. They may want to do it for the target case only, or for > both target and native. They may want to do it from their local.conf (with a > pn- > override?), from a .bbappend, or also from a distro configuration. It is also > complicated where these things may stack and the user may or may not need to > change a change to the PACKAGECONFIG. > > Again, going from memory, depending on which of those things a user wants to > do, > a ??=, ?=, = on the original PACKAGECONFIG may be more or less helpful.
Standardising on ?= has two goals. Firstly to avoid the unexpected result of ??= followed by +=, ie the trap which many users fall into, especially new users. The second is to make the more complex / contrived use cases at least behave consistently. Currently there are 180 ??= and 29 ?= assignments to PACKAGECONFIG in oe-core [*] (and 262 -vs- 61 in meta-oe), so whatever fallout you expect from standardizing is already hitting some users, some of the time. Since no one is complaining, I suspect it's either not a real issue or it's trivial to workaround. [*] Some recipes such as ovmf and ruby combine ??= and += directly in the recipe, so actually behave more like an assignment with ?=. > I can try and work through each of the scenarios and write down which of the > operators makes most sense in each case and it is probably such an analysis we > need. Usually most people believe their favourite use case is the only one > anyone could ever want and is therefore the right one though :/. I struggle to > do work like this when patches aren't merging, we need milestone builds and > the > autobuilder is showing breakage. > > Cheers, > > Richard >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1390): https://lists.openembedded.org/g/openembedded-architecture/message/1390 Mute This Topic: https://lists.openembedded.org/mt/87569589/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
