On Thu, 2020-05-21 at 11:09 +0200, Martin Jansa wrote: > On Thu, May 21, 2020 at 11:05 AM Martin Jansa via > lists.openembedded.org <[email protected] > > wrote: > > > > On Thu, May 21, 2020 at 10:54 AM Nicolas Dechesne < > > [email protected]> wrote: > > > > > > On Thu, May 21, 2020 at 10:40 AM Richard Purdie < > > > [email protected]> wrote: > > > > On Thu, 2020-05-21 at 09:31 +0100, Richard Purdie > > > > vialists.openembedded.org wrote: > > > > > b) to consider whether we should "ban" _remove from YP Compat > > > > layers? > > > > > I know even core has some these days although I have tried > > > > very hard > > > > > not to let them in. > > > > > > > > At a quick count, 64 usages in core sadly: > > > > > > I suppose _remove is (ab)used because we can append *only if* an > > > override is defined. So we are missing a constructor for append > > > if the override is not defined. e.g. > > > > > > PACKAGECONFIG_remove_libc-musl = "elf-tls" > > > to be replaced by > > > PACKAGECONFIG_append_!lib-musl = "elf-tls" > > > > > > which is exactly what the _remove statement is trying to express > > > here (and most likely in most of the _remove use in core). And it > > > would be a more social behavior. > > > > > > > For this I'm regularly using intermediate variable like > > PACKAGECONFIG_ELF_TLS = "elf-tls" > > PACKAGECONFIG_ELF_TLS_libc-musl = "" > > > > PACKAGECONFIG ??= "foo bar ${PACKAGECONFIG_ELF_TLS}" > > > > But these variables need to be prepared in the original layer with > > the recipe, so maintainers need to know in advance that such use > > case exists and prevent the _remove use. > > > > And if I really need to use _remove, then it's useful to use some > variable for the removed value (so that it can be again overridden by > someone who doesn't want it being remove), or some conditional like > here: > https://github.com/webosose/meta-webosose/commit/d0b237b70264e269f75303a11c43b2eea25de991
Right, there are ways some of these could (and probably should) be avoided. I guess the question is whether there is some kind of syntax or bitbake functionality which could improve the situation. Nico's observation is a good one. The hard part is when there are a list of exclusions e.g. !(lib-musl or mingw). So I think there are two problems: Situations where we have defaults which people might want to: * replace entirely * append to * remove from * change the defaults in future with user opt in (perhaps we need to redefine the behaviour of append/remove with ??= or add a new assignment type?) and Overuse of the remove operator due to weaknesses in "exclusion" overrides... Both issues are worth further thought. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1081): https://lists.openembedded.org/g/openembedded-architecture/message/1081 Mute This Topic: https://lists.openembedded.org/mt/74369459/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
