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

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

[Andre McCurdy]

Fix long standing quirk, _forcevariable is documented as being the
highest priority over-ride.

Signed-off-by: Andre McCurdy <armccurdy@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 ?= ""
 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}"
 
 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"
-- 
1.9.1

[PATCH 2/3] native.bbclass: drop _virtclass-native and _virtclass-nativesdk overrides

[Andre McCurdy]

The _virtclass-XXX over-rides are problematic in that they are higher
priority than _forcevariable, which is documented as being the
highest priority over-ride.

Since they are now obsolete (replaced by _class-native and
_class-nativesdk) drop them entirely rather than try to fix their
priority.

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 meta/classes/native.bbclass    | 2 --
 meta/classes/nativesdk.bbclass | 1 -
 2 files changed, 3 deletions(-)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 7f2df17..ad7e98a 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -154,8 +154,6 @@ python native_virtclass_handler () {
                 newdeps.append(dep)
         d.setVar(varname, " ".join(newdeps))
 
-    e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + ":virtclass-native")
-
     map_dependencies("DEPENDS", e.data)
     for pkg in [e.data.getVar("PN"), "", "${PN}"]:
         map_dependencies("RDEPENDS", e.data, pkg)
diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index 69fb45c8..ab566e9 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -78,7 +78,6 @@ python nativesdk_virtclass_handler () {
 
     e.data.setVar("MLPREFIX", "nativesdk-")
     e.data.setVar("PN", "nativesdk-" + e.data.getVar("PN").replace("-nativesdk", "").replace("nativesdk-", ""))
-    e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + ":virtclass-nativesdk")
 }
 
 python () {
-- 
1.9.1

[PATCH 3/3] bitbake.conf: drop _build-${BUILD_OS} over-ride

[Andre McCurdy]

Building on a host OS other than a recent version of Linux is not
recommended or supported. Drop the historical _build-${BUILD_OS}
over-ride to avoid giving the impression that other host OS's might
be supported.

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 meta/classes/cross.bbclass  | 1 -
 meta/classes/native.bbclass | 1 -
 meta/conf/bitbake.conf      | 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index 4e85cab2..34d7951 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -37,7 +37,6 @@ CPPFLAGS = "${BUILD_CPPFLAGS}"
 CFLAGS = "${BUILD_CFLAGS}"
 CXXFLAGS = "${BUILD_CFLAGS}"
 LDFLAGS = "${BUILD_LDFLAGS}"
-LDFLAGS_build-darwin = "-L${STAGING_LIBDIR_NATIVE}"
 
 TOOLCHAIN_OPTIONS = ""
 
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index ad7e98a..ddccfe2e1 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -44,7 +44,6 @@ CPPFLAGS = "${BUILD_CPPFLAGS}"
 CFLAGS = "${BUILD_CFLAGS}"
 CXXFLAGS = "${BUILD_CXXFLAGS}"
 LDFLAGS = "${BUILD_LDFLAGS}"
-LDFLAGS_build-darwin = "-L${STAGING_LIBDIR_NATIVE} "
 
 STAGING_BINDIR = "${STAGING_BINDIR_NATIVE}"
 STAGING_BINDIR_CROSS = "${STAGING_BINDIR_NATIVE}"
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index a772cab..702f498 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -735,7 +735,7 @@ 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}${LIBCOVERRIDE}:forcevariable"
+OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable"
 LIBCOVERRIDE ?= ""
 CLASSOVERRIDE ?= "class-target"
 DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
-- 
1.9.1

Re: [PATCH 3/3] bitbake.conf: drop _build-${BUILD_OS} over-ride

[Khem Raj]

On 5/9/18 8:14 PM, Andre McCurdy wrote:
> Building on a host OS other than a recent version of Linux is not
> recommended or supported. Drop the historical _build-${BUILD_OS}
> over-ride to avoid giving the impression that other host OS's might
> be supported.

if this is not causing issues, I would suggest to keep this in.

> 
> Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
> ---
>   meta/classes/cross.bbclass  | 1 -
>   meta/classes/native.bbclass | 1 -
>   meta/conf/bitbake.conf      | 2 +-
>   3 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
> index 4e85cab2..34d7951 100644
> --- a/meta/classes/cross.bbclass
> +++ b/meta/classes/cross.bbclass
> @@ -37,7 +37,6 @@ CPPFLAGS = "${BUILD_CPPFLAGS}"
>   CFLAGS = "${BUILD_CFLAGS}"
>   CXXFLAGS = "${BUILD_CFLAGS}"
>   LDFLAGS = "${BUILD_LDFLAGS}"
> -LDFLAGS_build-darwin = "-L${STAGING_LIBDIR_NATIVE}"
>   
>   TOOLCHAIN_OPTIONS = ""
>   
> diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
> index ad7e98a..ddccfe2e1 100644
> --- a/meta/classes/native.bbclass
> +++ b/meta/classes/native.bbclass
> @@ -44,7 +44,6 @@ CPPFLAGS = "${BUILD_CPPFLAGS}"
>   CFLAGS = "${BUILD_CFLAGS}"
>   CXXFLAGS = "${BUILD_CXXFLAGS}"
>   LDFLAGS = "${BUILD_LDFLAGS}"
> -LDFLAGS_build-darwin = "-L${STAGING_LIBDIR_NATIVE} "
>   
>   STAGING_BINDIR = "${STAGING_BINDIR_NATIVE}"
>   STAGING_BINDIR_CROSS = "${STAGING_BINDIR_NATIVE}"
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index a772cab..702f498 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -735,7 +735,7 @@ 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}${LIBCOVERRIDE}:forcevariable"
> +OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable"
>   LIBCOVERRIDE ?= ""
>   CLASSOVERRIDE ?= "class-target"
>   DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
> 

Re: [PATCH 3/3] bitbake.conf: drop _build-${BUILD_OS} over-ride

[Dan McGregor]

On 9 May 2018 at 23:44, Khem Raj <raj.khem@gmail.com> wrote:
>
>
> On 5/9/18 8:14 PM, Andre McCurdy wrote:
>>
>> Building on a host OS other than a recent version of Linux is not
>> recommended or supported. Drop the historical _build-${BUILD_OS}
>> over-ride to avoid giving the impression that other host OS's might
>> be supported.
>
>
> if this is not causing issues, I would suggest to keep this in.

I'm with Khem. meta-darwin and meta-mingw are things, even if they
haven't been updated in years. If interest arises they shouldn't have
too many barriers to starting development again. I've also started to
attempt to build on a FreeBSD host.

>
>
>>
>> Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
>> ---
>>   meta/classes/cross.bbclass  | 1 -
>>   meta/classes/native.bbclass | 1 -
>>   meta/conf/bitbake.conf      | 2 +-
>>   3 files changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
>> index 4e85cab2..34d7951 100644
>> --- a/meta/classes/cross.bbclass
>> +++ b/meta/classes/cross.bbclass
>> @@ -37,7 +37,6 @@ CPPFLAGS = "${BUILD_CPPFLAGS}"
>>   CFLAGS = "${BUILD_CFLAGS}"
>>   CXXFLAGS = "${BUILD_CFLAGS}"
>>   LDFLAGS = "${BUILD_LDFLAGS}"
>> -LDFLAGS_build-darwin = "-L${STAGING_LIBDIR_NATIVE}"
>>     TOOLCHAIN_OPTIONS = ""
>>   diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
>> index ad7e98a..ddccfe2e1 100644
>> --- a/meta/classes/native.bbclass
>> +++ b/meta/classes/native.bbclass
>> @@ -44,7 +44,6 @@ CPPFLAGS = "${BUILD_CPPFLAGS}"
>>   CFLAGS = "${BUILD_CFLAGS}"
>>   CXXFLAGS = "${BUILD_CXXFLAGS}"
>>   LDFLAGS = "${BUILD_LDFLAGS}"
>> -LDFLAGS_build-darwin = "-L${STAGING_LIBDIR_NATIVE} "
>>     STAGING_BINDIR = "${STAGING_BINDIR_NATIVE}"
>>   STAGING_BINDIR_CROSS = "${STAGING_BINDIR_NATIVE}"
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index a772cab..702f498 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -735,7 +735,7 @@ 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}${LIBCOVERRIDE}:forcevariable"
>> +OVERRIDES =
>> "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable"
>>   LIBCOVERRIDE ?= ""
>>   CLASSOVERRIDE ?= "class-target"
>>   DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
>>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 3/3] bitbake.conf: drop _build-${BUILD_OS} over-ride

[Burton, Ross]

On 10 May 2018 at 16:47, Dan McGregor <danismostlikely@gmail.com> wrote:
> I'm with Khem. meta-darwin and meta-mingw are things, even if they
> haven't been updated in years. If interest arises they shouldn't have
> too many barriers to starting development again. I've also started to
> attempt to build on a FreeBSD host.

meta-mingw builds Windows binaries from Linux and meta-darwin builds
Darwin binaries from Linux, so they're not relevant.

People *are* at least trying to use Windows Subsystem for Linux to
build Yocto on Windows, but I suspect as far as bitbake is concerned
that is Linux.  There's no practical way we can build on macOS right
now due to the recent security changes.

Builds on BSD would be interesting, I'm curious as to how much breaks
from GNU userland expectations and whether the build override is
actually useful.

Ross

Re: [PATCH 3/3] bitbake.conf: drop _build-${BUILD_OS} over-ride

[Dan McGregor]

On 10 May 2018 at 10:33, Burton, Ross <ross.burton@intel.com> wrote:
> On 10 May 2018 at 16:47, Dan McGregor <danismostlikely@gmail.com> wrote:
>> I'm with Khem. meta-darwin and meta-mingw are things, even if they
>> haven't been updated in years. If interest arises they shouldn't have
>> too many barriers to starting development again. I've also started to
>> attempt to build on a FreeBSD host.
>
> meta-mingw builds Windows binaries from Linux and meta-darwin builds
> Darwin binaries from Linux, so they're not relevant.

Neat, I only took a quick look; I guess I misinterpreted their purposes.

>
> People *are* at least trying to use Windows Subsystem for Linux to
> build Yocto on Windows, but I suspect as far as bitbake is concerned
> that is Linux.  There's no practical way we can build on macOS right
> now due to the recent security changes.

When I tried, early in the WSL testing, bitbake wouldn't start due to
some missing syscalls. inotify related, IIRC.

>
> Builds on BSD would be interesting, I'm curious as to how much breaks
> from GNU userland expectations and whether the build override is
> actually useful.

The problem I'm running into right now is pseudo. FreeBSD uses a
different API for extended attributes, so all the various xattr_...
things don't work. I might need to make it depend on a port of the
xattr wrappers.

Outside of that, I've been using a FreeBSD hosted cross toolchain for
embedded Linux for years. It works well on its own. Hopefully the
build-* overrides will be helpful for the small differences I've
noticed.

>
> Ross

Re: [PATCH 3/3] bitbake.conf: drop _build-${BUILD_OS} over-ride

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

Even if bitbake could run on WSL, it’d be horribly slow. I/O on WSL is
*terrible* right now, docker or a VM wipes the floor with it. I’m sure
it’ll be viable eventually, though :)

On Thu, May 10, 2018 at 10:09 AM, Dan McGregor <danismostlikely@gmail.com>
wrote:

> On 10 May 2018 at 10:33, Burton, Ross <ross.burton@intel.com> wrote:
> > On 10 May 2018 at 16:47, Dan McGregor <danismostlikely@gmail.com> wrote:
> >> I'm with Khem. meta-darwin and meta-mingw are things, even if they
> >> haven't been updated in years. If interest arises they shouldn't have
> >> too many barriers to starting development again. I've also started to
> >> attempt to build on a FreeBSD host.
> >
> > meta-mingw builds Windows binaries from Linux and meta-darwin builds
> > Darwin binaries from Linux, so they're not relevant.
>
> Neat, I only took a quick look; I guess I misinterpreted their purposes.
>
> >
> > People *are* at least trying to use Windows Subsystem for Linux to
> > build Yocto on Windows, but I suspect as far as bitbake is concerned
> > that is Linux.  There's no practical way we can build on macOS right
> > now due to the recent security changes.
>
> When I tried, early in the WSL testing, bitbake wouldn't start due to
> some missing syscalls. inotify related, IIRC.
>
> >
> > Builds on BSD would be interesting, I'm curious as to how much breaks
> > from GNU userland expectations and whether the build override is
> > actually useful.
>
> The problem I'm running into right now is pseudo. FreeBSD uses a
> different API for extended attributes, so all the various xattr_...
> things don't work. I might need to make it depend on a port of the
> xattr wrappers.
>
> Outside of that, I've been using a FreeBSD hosted cross toolchain for
> embedded Linux for years. It works well on its own. Hopefully the
> build-* overrides will be helpful for the small differences I've
> noticed.
>
> >
> > Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 3374 bytes --]

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

[Khem Raj]

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@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

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.

>   
>   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"
> 

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

[Andre McCurdy]

On Wed, May 9, 2018 at 10:41 PM, Khem Raj <raj.khem@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@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

> 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"
>>
>

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

[Khem Raj]

On Thu, May 10, 2018 at 3:33 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Wed, May 9, 2018 at 10:41 PM, Khem Raj <raj.khem@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@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.

>> 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"
>>>
>>

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

[Andre McCurdy]

On Thu, May 10, 2018 at 3:40 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 10, 2018 at 3:33 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Wed, May 9, 2018 at 10:41 PM, Khem Raj <raj.khem@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@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"
>>>>
>>>