[OE-core] [PATCH 1/3] bitbake.conf: make libc over-ride lower priority than _forcevariable

Andre McCurdy armccurdy at gmail.com
Fri May 11 00:53:41 UTC 2018


On Thu, May 10, 2018 at 3:40 PM, Khem Raj <raj.khem at gmail.com> wrote:
> On Thu, May 10, 2018 at 3:33 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
>> On Wed, May 9, 2018 at 10:41 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>> On 5/9/18 8:14 PM, Andre McCurdy wrote:
>>>>
>>>> Fix long standing quirk, _forcevariable is documented as being the
>>>> highest priority over-ride.
>>>>
>>>> Signed-off-by: Andre McCurdy <armccurdy at gmail.com>
>>>> ---
>>>>   meta/conf/bitbake.conf                        | 3 ++-
>>>>   meta/conf/distro/include/tclibc-baremetal.inc | 2 --
>>>>   meta/conf/distro/include/tclibc-glibc.inc     | 2 --
>>>>   meta/conf/distro/include/tclibc-musl.inc      | 2 --
>>>>   4 files changed, 2 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>>> index a21b728..a772cab 100644
>>>> --- a/meta/conf/bitbake.conf
>>>> +++ b/meta/conf/bitbake.conf
>>>> @@ -735,7 +735,8 @@ DISTRO_NAME ??= "OpenEmbedded"
>>>>   #
>>>>   # This works for  functions as well, they are really just environment
>>>> variables.
>>>>   # Default OVERRIDES to make compilation fail fast in case of build
>>>> system misconfiguration.
>>>> -OVERRIDES =
>>>> "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
>>>> +OVERRIDES =
>>>> "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable"
>>>> +LIBCOVERRIDE ?= ""
>>>
>>>
>>> Overall this looks an improvement
>>>
>>>>   CLASSOVERRIDE ?= "class-target"
>>>>   DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
>>>>   MACHINEOVERRIDES ?= "${MACHINE}"
>>>> diff --git a/meta/conf/distro/include/tclibc-baremetal.inc
>>>> b/meta/conf/distro/include/tclibc-baremetal.inc
>>>> index 8d570f0..1bf44c8 100644
>>>> --- a/meta/conf/distro/include/tclibc-baremetal.inc
>>>> +++ b/meta/conf/distro/include/tclibc-baremetal.inc
>>>> @@ -4,9 +4,7 @@
>>>>     LIBCEXTENSION = ""
>>>>   -# Add baremetal libc overrides to the overrides.
>>>>   LIBCOVERRIDE = ":libc-baremetal"
>>>> -OVERRIDES .= "${LIBCOVERRIDE}"
>>>>     ASSUME_PROVIDED += "virtual/libc virtual/libiconv virtual/crypt"
>>>>   diff --git a/meta/conf/distro/include/tclibc-glibc.inc
>>>> b/meta/conf/distro/include/tclibc-glibc.inc
>>>> index ad8000f..8d10764 100644
>>>> --- a/meta/conf/distro/include/tclibc-glibc.inc
>>>> +++ b/meta/conf/distro/include/tclibc-glibc.inc
>>>> @@ -4,9 +4,7 @@
>>>>     LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION') or '') !=
>>>> '']}"
>>>>   -# Add glibc overrides to the overrides for glibc.
>>>>   LIBCOVERRIDE = ":libc-glibc"
>>>> -OVERRIDES .= "${LIBCOVERRIDE}"
>>>
>>>
>>> having .= appear was letting user know how it was being lined up in
>>> overrides, now it might raise question in new readers mind as to why ':' is
>>> prepended
>>
>> Yes, it's a shame LIBCOVERRIDE was defined with a leading : to begin
>> with, but now it's done that way I'm not sure it's worth redefining
>> (there could be classes or recipe in other layers which reference
>> LIBCOVERRIDE and expect the leading : to be there).
>>
>>   http://git.openembedded.org/openembedded-core/commit/?id=6e2b53f47da0e97271fb51b281d24da1e1d549cc
>
> oh in this case then please remove it, its not an ABI element that
> we need to keep compatibility with and layers who use it should
> change to new ways.

A patch removing the leading : was rejected about a month ago:

  http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149742.html
  http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149743.html

If you think RP was wrong then maybe reply to that thread and try to
get the original patch merged?

>>> so ideally it would be good to define LIBCOVERRIDE = "libc-<libc>" but that
>>> might add useless : in case of native recipes
>>>
>>> Maybe bitbake should just eat consecutive separators without consequence but
>>> that seems less than ideal too.
>>
>> Bitbake already does eat consecutive separators (it needs to for
>> native recipes, since native recipes set MACHINEOVERRIDES to "").
>>
>>>>     PREFERRED_PROVIDER_virtual/libiconv ?= "glibc"
>>>>   PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= "nativesdk-glibc"
>>>> diff --git a/meta/conf/distro/include/tclibc-musl.inc
>>>> b/meta/conf/distro/include/tclibc-musl.inc
>>>> index 54e1acf..052ae0e 100644
>>>> --- a/meta/conf/distro/include/tclibc-musl.inc
>>>> +++ b/meta/conf/distro/include/tclibc-musl.inc
>>>> @@ -4,9 +4,7 @@
>>>>     LIBCEXTENSION = "-musl"
>>>>   -# Add musl libc overrides to the overrides.
>>>>   LIBCOVERRIDE = ":libc-musl"
>>>> -OVERRIDES .= "${LIBCOVERRIDE}"
>>>>     PREFERRED_PROVIDER_virtual/libc ?= "musl"
>>>>   PREFERRED_PROVIDER_virtual/libiconv ?= "musl"
>>>>
>>>



More information about the Openembedded-core mailing list