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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1080): https://lists.openembedded.org/g/openembedded-architecture/message/1080 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]] -=-=-=-=-=-=-=-=-=-=-=-
