bitbake.conf: make libc over-ride lower priority than _forcevariable

PATCH In review Andre McCurdy 5 participants 12 messages May 10, 2018 – May 11, 2018

lore

Share & tools

lore

Andre McCurdy

author

2018-05-10 03:15 UTC #0 lore raw

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

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

Signed-off-by Andre McCurdy <[email protected]>

---
 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(-)

meta/conf/bitbake.conf +2 -1

index a21b728..a772cab 100644
@@ -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}"

meta/conf/distro/include/tclibc-baremetal.inc +0 -2

index 8d570f0..1bf44c8 100644
@@ -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"

meta/conf/distro/include/tclibc-glibc.inc +0 -2

index ad8000f..8d10764 100644
@@ -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"

meta/conf/distro/include/tclibc-musl.inc +0 -2

index 54e1acf..052ae0e 100644
@@ -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"

Signature · 1 line

1.9.1

Andre McCurdy

author

2018-05-10 03:15 UTC #1 lore raw

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

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 <[email protected]>

---
 meta/classes/native.bbclass    | 2 --
 meta/classes/nativesdk.bbclass | 1 -
 2 files changed, 3 deletions(-)

meta/classes/native.bbclass +0 -2

index 7f2df17..ad7e98a 100644
@@ -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)

meta/classes/nativesdk.bbclass +0 -1

index 69fb45c8..ab566e9 100644
@@ -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 () {

Signature · 1 line

1.9.1

Andre McCurdy

author

2018-05-10 03:15 UTC #2 lore raw

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

In reply to 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 <[email protected]>

---
 meta/classes/cross.bbclass  | 1 -
 meta/classes/native.bbclass | 1 -
 meta/conf/bitbake.conf      | 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

meta/classes/cross.bbclass +0 -1

index 4e85cab2..34d7951 100644
@@ -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 = ""

meta/classes/native.bbclass +0 -1

index ad7e98a..ddccfe2e1 100644
@@ -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}"

meta/conf/bitbake.conf +1 -1

index a772cab..702f498 100644
@@ -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 ''}"

Signature · 1 line

1.9.1

Khem Raj

2018-05-10 05:44 UTC #3 lore raw

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

Quoted 4 lines · 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.

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

Quoted 46 lines

Signed-off-by Andre McCurdy <[email protected]>

---
  meta/classes/cross.bbclass  | 1 -
  meta/classes/native.bbclass | 1 -
  meta/conf/bitbake.conf      | 2 +-
  3 files changed, 1 insertion(+), 3 deletions(-)

meta/classes/cross.bbclass +0 -1

index 4e85cab2..34d7951 100644
@@ -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 = ""

meta/classes/native.bbclass +0 -1

index ad7e98a..ddccfe2e1 100644
@@ -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}"

meta/conf/bitbake.conf +1 -1

index a772cab..702f498 100644
@@ -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 ''}"

Dan McGregor

2018-05-10 15:47 UTC #4 lore raw

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

Quoted 11 lines · Khem Raj

Quoted 5 lines · 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.
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.

Quoted 54 lines

Quoted 40 lines
Signed-off-by Andre McCurdy <[email protected]>
---
  meta/classes/cross.bbclass  | 1 -
  meta/classes/native.bbclass | 1 -
  meta/conf/bitbake.conf      | 2 +-
  3 files changed, 1 insertion(+), 3 deletions(-)
meta/classes/cross.bbclass +0 -1
index 4e85cab2..34d7951 100644
@@ -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
meta/classes/native.bbclass +0 -1
@@ -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}"
meta/conf/bitbake.conf +0 -0
index a772cab..702f498 100644
@@ -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
Quoted 9 lines
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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Burton, Ross

2018-05-10 16:33 UTC #5 lore raw

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

Quoted 4 lines · Dan McGregor

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

Dan McGregor

2018-05-10 17:09 UTC #6 lore raw

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

Quoted 8 lines · Ross

Quoted 4 lines · Dan McGregor
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.

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

Ross

Christopher Larson

2018-05-10 17:57 UTC #7 lore raw

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

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 :)

Quoted 44 lines · Dan McGregor

Quoted 8 lines · Ross
Quoted 4 lines · Dan McGregor
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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 2 lines
Ross
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 4 lines

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

Khem Raj

2018-05-10 05:41 UTC #8 lore raw

In reply to Andre McCurdy

Quoted 16 lines · Andre McCurdy

Fix long standing quirk, _forcevariable is documented as being the highest priority over-ride.
Signed-off-by Andre McCurdy <[email protected]>
---
  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(-)
meta/conf/bitbake.conf +0 -0
index a21b728..a772cab 100644

meta/conf/bitbake.conf DISTRO_NAME ??= "OpenEmbedded" · line 739

Quoted 6 lines

meta/conf/bitbake.conf +2 -1

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

Quoted 22 lines

meta/conf/bitbake.conf +0 -0

  CLASSOVERRIDE ?= "class-target"
  DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
  MACHINEOVERRIDES ?= "${MACHINE}"

meta/conf/distro/include/tclibc-baremetal.inc +0 -2

index 8d570f0..1bf44c8 100644
@@ -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"

meta/conf/distro/include/tclibc-glibc.inc +0 -0

index ad8000f..8d10764 100644

meta/conf/distro/include/tclibc-glibc.inc line 9

Quoted 6 lines

meta/conf/distro/include/tclibc-glibc.inc +0 -2

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

Quoted 18 lines

meta/conf/distro/include/tclibc-glibc.inc +0 -0

  PREFERRED_PROVIDER_virtual/libiconv ?= "glibc"
  PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= "nativesdk-glibc"

meta/conf/distro/include/tclibc-musl.inc +0 -2

index 54e1acf..052ae0e 100644
@@ -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"

Andre McCurdy

author

2018-05-10 22:33 UTC #9 lore raw

Quoted 54 lines · Khem Raj

Quoted 19 lines · Andre McCurdy
Fix long standing quirk, _forcevariable is documented as being the highest priority over-ride.
Signed-off-by Andre McCurdy <[email protected]>
---
  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(-)
meta/conf/bitbake.conf +0 -0
index a21b728..a772cab 100644
@@ -735,7 +735,8 @@ DISTRO_NAME ??= "OpenEmbedded"
  #
  # This works for  functions as well, they are really just environment
Quoted 8 lines
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
Quoted 22 lines
  CLASSOVERRIDE ?= "class-target"
  DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
  MACHINEOVERRIDES ?= "${MACHINE}"
meta/conf/distro/include/tclibc-baremetal.inc +0 -1
index 8d570f0..1bf44c8 100644
@@ -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
meta/conf/distro/include/tclibc-glibc.inc +0 -0
@@ -4,9 +4,7 @@
    LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION') or '') !=
'']}"

Quoted 8 lines

Quoted 3 lines
-# 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

Quoted 5 lines

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

Quoted 16 lines

Quoted 15 lines
PREFERRED_PROVIDER_virtual/libiconv ?= "glibc"
PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= "nativesdk-glibc"
meta/conf/distro/include/tclibc-musl.inc +0 -1
index 54e1acf..052ae0e 100644
@@ -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"
 

Khem Raj

2018-05-10 22:41 UTC #10 lore raw

Quoted 64 lines · Andre McCurdy

Quoted 54 lines · Khem Raj
Quoted 19 lines · Andre McCurdy
Fix long standing quirk, _forcevariable is documented as being the highest priority over-ride.
Signed-off-by Andre McCurdy <[email protected]>
---
  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(-)
meta/conf/bitbake.conf +0 -0
index a21b728..a772cab 100644
@@ -735,7 +735,8 @@ DISTRO_NAME ??= "OpenEmbedded"
  #
  # This works for  functions as well, they are really just environment
Quoted 8 lines
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
Quoted 22 lines
  CLASSOVERRIDE ?= "class-target"
  DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
  MACHINEOVERRIDES ?= "${MACHINE}"
meta/conf/distro/include/tclibc-baremetal.inc +0 -1
index 8d570f0..1bf44c8 100644
@@ -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
meta/conf/distro/include/tclibc-glibc.inc +0 -0
@@ -4,9 +4,7 @@
    LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION') or '') !=
'']}"
Quoted 8 lines
Quoted 3 lines
-# 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

Quoted 7 lines

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.

Quoted 25 lines

Quoted 5 lines
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 "").
Quoted 16 lines
Quoted 15 lines
PREFERRED_PROVIDER_virtual/libiconv ?= "glibc"
PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= "nativesdk-glibc"
meta/conf/distro/include/tclibc-musl.inc +0 -1
index 54e1acf..052ae0e 100644
@@ -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"
 

Andre McCurdy

author

2018-05-11 00:53 UTC #11 lore raw

Quoted 70 lines · Khem Raj

Quoted 69 lines · Andre McCurdy
Quoted 54 lines · Khem Raj
Quoted 19 lines · Andre McCurdy
Fix long standing quirk, _forcevariable is documented as being the highest priority over-ride.
Signed-off-by Andre McCurdy <[email protected]>
---
  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(-)
meta/conf/bitbake.conf +0 -0
index a21b728..a772cab 100644
@@ -735,7 +735,8 @@ DISTRO_NAME ??= "OpenEmbedded"
  #
  # This works for  functions as well, they are really just environment
Quoted 8 lines
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
Quoted 22 lines
  CLASSOVERRIDE ?= "class-target"
  DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
  MACHINEOVERRIDES ?= "${MACHINE}"
meta/conf/distro/include/tclibc-baremetal.inc +0 -1
index 8d570f0..1bf44c8 100644
@@ -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
meta/conf/distro/include/tclibc-glibc.inc +0 -0
@@ -4,9 +4,7 @@
    LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION') or '') !=
'']}"
Quoted 8 lines
Quoted 3 lines
-# 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).

Quoted 5 lines

Quoted 1 line
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?

Quoted 25 lines

Quoted 25 lines
Quoted 5 lines
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 "").
Quoted 16 lines
Quoted 15 lines
PREFERRED_PROVIDER_virtual/libiconv ?= "glibc"
PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= "nativesdk-glibc"
meta/conf/distro/include/tclibc-musl.inc +0 -1
index 54e1acf..052ae0e 100644
@@ -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"
 