Pending patches

PATCH Applied Martin Jansa 5 participants 18 messages Feb 26, 2012 – Apr 27, 2012

lore

Share & tools

lore

Martin Jansa

author

2012-02-26 07:57 UTC #0 lore raw

v2 cover Pending patches

Patch 0003 depends on
http://patchwork.openembedded.org/patch/22047/

0001 wasn't changed from v1, but still does apply.

0004/0005 is the same as I've sent as single patches to ML before.

The following changes since commit c44e51f281101c8933679f679e3d4a75a41bedf7:

initscripts: mount and unmount cifs network filesystems (2012-02-24 23:25:33 +0000)

are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib jansa/pull
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/pull

Eric BENARD (1):
gdb-cross-canadian: build gdb with python support

Martin Jansa (4):
bitbake.conf: use weak assignment for BB_CONSOLELOG bitbake.conf: remove TARGET_ARCH from in SDKPATH
sstatesig: add SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS option to exclude well

    defined recipe->dependency

layer.conf: add keymaps to SIGGEN_EXCLUDERECIPES_ABISAFE

 meta/conf/bitbake.conf                             |   12 +++++++++---
 meta/conf/layer.conf                               |    1 +
 meta/lib/oe/sstatesig.py                           |    6 ++++++
 meta/recipes-devtools/gdb/gdb-cross-canadian.inc   |   20 +++++++++++++++++++-
 .../recipes-devtools/gdb/gdb-cross-canadian_7.4.bb |    2 +-
 5 files changed, 36 insertions(+), 5 deletions(-)

Signature · 1 line

1.7.8.4

Martin Jansa

author

2012-02-26 07:58 UTC #1 lore raw

PATCH v2 1/5 bitbake.conf: use weak assignment for BB_CONSOLELOG

* some people prefer subdirectory like ${TMPDIR}/cooker/${DATETIME}.log

Signed-off-by Martin Jansa <[email protected]>

---
 meta/conf/bitbake.conf |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

meta/conf/bitbake.conf +2 -1

index 2539ae0..55daa9e 100644
@@ -726,7 +726,8 @@ DISTRO[unexport] = "1"
 # Used by canadian-cross to handle string conversions on TARGET_ARCH where needed
 TRANSLATED_TARGET_ARCH ??= "${@d.getVar('TARGET_ARCH', True).replace("_", "-")}"
 
-BB_CONSOLELOG = "${TMPDIR}/cooker.log.${DATETIME}"
+# Complete output from bitbake, if you're changing it, make sure to use existing directory
+BB_CONSOLELOG ?= "${TMPDIR}/cooker.log.${DATETIME}"
 
 # Setup our default hash policy
 BB_SIGNATURE_HANDLER ?= "OEBasic"

Signature · 1 line

1.7.8.4

Martin Jansa

author

2012-02-26 07:58 UTC #2 lore raw

PATCH v2 2/5 bitbake.conf: remove TARGET_ARCH from in SDKPATH

* SDKPATH shouldn't depend on TARGET_ARCH as discused here:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-February/018222.html
* introduce SDK_NAME_PREFIX so that distributions can overwrite only this instead of whole SDK_NAME

Signed-off-by Martin Jansa <[email protected]>

---
 meta/conf/bitbake.conf |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

meta/conf/bitbake.conf +7 -2

index 55daa9e..f2666cb 100644
@@ -360,8 +360,13 @@ DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools"
 
 PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
 
-SDK_NAME = "oecore-${SDK_ARCH}-${TARGET_ARCH}"
-SDKPATH = "/usr/local/${SDK_NAME}"
+##################################################################
+# SDK variables, 
+##################################################################
+
+SDK_NAME_PREFIX = "oecore"
+SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TARGET_ARCH}"
+SDKPATH = "/usr/local/${SDK_NAME_PREFIX}-${SDK_ARCH}"
 SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
 
 ##################################################################

Signature · 1 line

1.7.8.4

Martin Jansa

author

2012-02-26 07:58 UTC #14 lore raw

PATCH v2 3/5 gdb-cross-canadian: build gdb with python support

In reply to Martin Jansa

From: Eric BENARD <[email protected]>

* python support is needed for providing finer scripting control in gdb, and for remote controling gdb for example from qtcreator
* gdb/configure tries to autodetect python using python executable with --includes --ldflags --exec-prefix to get the right flags As it's difficult to achieve in OE's context, we generate a script which will return the right values and make gdb's build system happy. This idea was taken from the following article :
http://www.mentby.com/doug-evans-2/python-enabled-gdb-on-windows-and-relocation.html
* tested using angstrom & armv7 target & qtcreator 201005 & 2.4.0

* MJ: updated paths to python as disscussed here
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-February/018222.html
now it's easier with cross-canadian staging dir and SDKPATH fixed :)

Signed-off-by Eric Bénard <[email protected]>

Cc [email protected]

Signed-off-by Martin Jansa <[email protected]>

---
 meta/recipes-devtools/gdb/gdb-cross-canadian.inc   |   20 +++++++++++++++++++-
 .../recipes-devtools/gdb/gdb-cross-canadian_7.4.bb |    2 +-
 2 files changed, 20 insertions(+), 2 deletions(-)

meta/recipes-devtools/gdb/gdb-cross-canadian.inc +19 -1

index ec0748e..a7cac61 100644
@@ -4,4 +4,22 @@ DESCRIPTION = "cross-canadian gdb for ${TARGET_ARCH} target - GNU debugger"
 PN = "gdb-cross-canadian-${TRANSLATED_TARGET_ARCH}"
 BPN = "gdb"
 
-DEPENDS = "ncurses-nativesdk expat-nativesdk gettext-nativesdk readline-nativesdk"
+DEPENDS = "ncurses-nativesdk expat-nativesdk gettext-nativesdk readline-nativesdk python-nativesdk"
+RDEPENDS += "python-nativesdk-core python-nativesdk-lang python-nativesdk-re \
+             python-nativesdk-codecs python-nativesdk-netclient"
+
+EXTRA_OECONF_append = "--with-python=${WORKDIR}/python"
+
+do_configure_prepend() {
+cat > ${WORKDIR}/python << EOF
+#! /bin/sh
+case "\$2" in
+        --includes) echo "-I${STAGING_INCDIR}/python${PYTHON_BASEVERSION}/" ;;
+        --ldflags) echo "-L${STAGING_LIBDIR}/../python${PYTHON_BASEVERSION}/config -lpthread -ldl -lutil -lm -lpython${PYTHON_BASEVERSION}" ;;
+        --exec-prefix) echo "/usr" ;;
+        *) exit 1 ;;
+esac
+exit 0
+EOF
+        chmod +x ${WORKDIR}/python
+}

meta/recipes-devtools/gdb/gdb-cross-canadian_7.4.bb +1 -1

index a4714e7..dbcffde 100644
@@ -1,7 +1,7 @@
 require gdb-common.inc
 require gdb-cross-canadian.inc
 
-PR = "${INC_PR}.1"
+PR = "${INC_PR}.3"
 
 GDBPROPREFIX = "--program-prefix='${TARGET_PREFIX}'"
 EXPAT = "--with-expat"

Signature · 1 line

1.7.8.4

Martin Jansa

author

2012-02-26 07:58 UTC #15 lore raw

PATCH v2 4/5 sstatesig: add SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS option to exclude well defined recipe->dependency

In reply to Martin Jansa

Signed-off-by Martin Jansa <[email protected]>

---
 meta/lib/oe/sstatesig.py |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

meta/lib/oe/sstatesig.py +6 -0

index 7b80c18..1c25823 100644
@@ -33,6 +33,10 @@ def sstate_rundepfilter(siggen, fn, recipename, task, dep, depname, dataCache):
     if depname in siggen.abisaferecipes:
         return False
 
+    # Exclude well defined recipe->dependency
+    if "%s->%s" % (recipename, depname) in siggen.saferecipedeps:
+        return False
+
     # Kernel modules are well namespaced. We don't want to depend on the kernel's checksum
     # if we're just doing an RRECOMMENDS_xxx = "kernel-module-*", not least because the checksum
     # is machine specific.

@@ -51,6 +55,7 @@ class SignatureGeneratorOEBasic(bb.siggen.SignatureGeneratorBasic):
     name = "OEBasic"
     def init_rundepcheck(self, data):
         self.abisaferecipes = (data.getVar("SIGGEN_EXCLUDERECIPES_ABISAFE", True) or "").split()
+        self.saferecipedeps = (data.getVar("SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS", True) or "").split()
         pass
     def rundep_check(self, fn, recipename, task, dep, depname, dataCache = None):
         return sstate_rundepfilter(self, fn, recipename, task, dep, depname, dataCache)

@@ -59,6 +64,7 @@ class SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
     name = "OEBasicHash"
     def init_rundepcheck(self, data):
         self.abisaferecipes = (data.getVar("SIGGEN_EXCLUDERECIPES_ABISAFE", True) or "").split()
+        self.saferecipedeps = (data.getVar("SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS", True) or "").split()
         pass
     def rundep_check(self, fn, recipename, task, dep, depname, dataCache = None):
         return sstate_rundepfilter(self, fn, recipename, task, dep, depname, dataCache)

Signature · 1 line

1.7.8.4

Martin Jansa

author

2012-02-26 07:58 UTC #16 lore raw

PATCH v2 5/5 layer.conf: add keymaps to SIGGEN_EXCLUDERECIPES_ABISAFE

In reply to Martin Jansa

Signed-off-by Martin Jansa <[email protected]>

---
 meta/conf/layer.conf |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

meta/conf/layer.conf +1 -0

index dac9c97..93c087a 100644
@@ -27,4 +27,5 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += " \
   xserver-xf86-config \
   pointercal \
   base-files \
+  keymaps \
 "

Signature · 1 line

1.7.8.4

Richard Purdie

Applied

2012-02-26 11:10 UTC #17 lore raw

In reply to Martin Jansa

Quoted 18 lines · Martin Jansa

Patch 0003 depends on
http://patchwork.openembedded.org/patch/22047/
0001 wasn't changed from v1, but still does apply.
0004/0005 is the same as I've sent as single patches to ML before.
The following changes since commit c44e51f281101c8933679f679e3d4a75a41bedf7:
initscripts: mount and unmount cifs network filesystems (2012-02-24 23:25:33 +0000)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib jansa/pull
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/pull
Eric BENARD (1):
gdb-cross-canadian: build gdb with python support

Quoted 6 lines

Martin Jansa (4):
bitbake.conf: use weak assignment for BB_CONSOLELOG bitbake.conf: remove TARGET_ARCH from in SDKPATH
sstatesig: add SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS option to exclude well
    defined recipe->dependency
layer.conf: add keymaps to SIGGEN_EXCLUDERECIPES_ABISAFE

Merged to master, thanks.

Richard

Khem Raj

2012-03-01 09:32 UTC #3 lore raw

Re: [PATCHv2 2/5] bitbake.conf: remove TARGET_ARCH from in SDKPATH

In reply to Martin Jansa

Quoted 1 line · Martin Jansa

+SDK_NAME_PREFIX = "oecore"

should this be weak assignment

Martin Jansa

author

2012-03-01 09:49 UTC #4 lore raw

Re: [PATCHv2 2/5] bitbake.conf: remove TARGET_ARCH from in SDKPATH

Quoted 4 lines · Khem Raj

Quoted 1 line · Martin Jansa
+SDK_NAME_PREFIX = "oecore"
should this be weak assignment

Yeah, probably could be (I'm not overwritting this from my distro conf so I haven't tried), but SDK_NAME assignment also wasn't weak and distros were overwritting it.

Someone with custom SDK_NAME(_PREFIX) please try and send patch.

Cheers,

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Martin Jansa

author

2012-03-01 18:34 UTC #5 lore raw

Re: [PATCHv2 2/5] bitbake.conf: remove TARGET_ARCH from in SDKPATH

Quoted 11 lines · Martin Jansa

Quoted 4 lines · Khem Raj
Quoted 1 line · Martin Jansa
+SDK_NAME_PREFIX = "oecore"
should this be weak assignment
Yeah, probably could be (I'm not overwritting this from my distro conf so I haven't tried), but SDK_NAME assignment also wasn't weak and distros were overwritting it.
Someone with custom SDK_NAME(_PREFIX) please try and send patch.

And we should change TARGET_ARCH in SDK_NAME to
PACKAGE_ARCH or TUNE_PKGARCH

because meta-toolchain-gmae for armv7a ends in oecore-i686-arm-toolchain-gmae-20120229.tar.bz2
and for armv4t with similar name (I was lucky that it took more then day to build)
oecore-i686-arm-toolchain-gmae-20120301.tar.bz2

Cheers,

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Richard Purdie

2012-03-01 20:08 UTC #6 lore raw

Re: [PATCHv2 2/5] bitbake.conf: remove TARGET_ARCH from in SDKPATH

Quoted 13 lines · Martin Jansa

Quoted 11 lines · Martin Jansa
Quoted 4 lines · Khem Raj
Quoted 1 line · Martin Jansa
+SDK_NAME_PREFIX = "oecore"
should this be weak assignment
Yeah, probably could be (I'm not overwritting this from my distro conf so I haven't tried), but SDK_NAME assignment also wasn't weak and distros were overwritting it.
Someone with custom SDK_NAME(_PREFIX) please try and send patch.

Quoted 8 lines

And we should change TARGET_ARCH in SDK_NAME to
PACKAGE_ARCH or TUNE_PKGARCH
because meta-toolchain-gmae for armv7a ends in oecore-i686-arm-toolchain-gmae-20120229.tar.bz2
and for armv4t with similar name (I was lucky that it took more then day to build)
oecore-i686-arm-toolchain-gmae-20120301.tar.bz2

Agreed...

Cheers,

Richard

Martin Jansa

author

2012-03-09 06:57 UTC #7 lore raw

PATCH 1/1 bitbake.conf: use PACKAGE_ARCH instead of TARGET_ARCH in SDK_NAME

In reply to Martin Jansa

* also use weak assignment for SDK_NAME_PREFIX as suggested by khem
* PACKAGE_ARCH is not 100% right too, because such SDK image usually has few machine specific packages included (e.g. base-files, securetty, opkg configs) but those are not important for SDK users so it's better to have one SDK for whole e.g. armv7a-vfp-neon then 6 SDK for each machine which would work the same.
You can see diff between crespo and om-gta04 SDK here:
http://build.shr-project.org/shr-core-staging/031/sdk/oecore-i686-armv7a-vfp-neon-toolchain-efl-crespo-om-gta04.diff

Signed-off-by Martin Jansa <[email protected]>

---
 meta/conf/bitbake.conf |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

meta/conf/bitbake.conf +2 -2

index 87bb71c..91f8397 100644
@@ -364,8 +364,8 @@ PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
 # SDK variables, 
 ##################################################################
 
-SDK_NAME_PREFIX = "oecore"
-SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TARGET_ARCH}"
+SDK_NAME_PREFIX ?= "oecore"
+SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${PACKAGE_ARCH}"
 SDKPATH = "/usr/local/${SDK_NAME_PREFIX}-${SDK_ARCH}"
 SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"

Signature · 1 line

1.7.8.5

McClintock Matthew-B29882

2012-03-09 16:41 UTC #8 lore raw

Re: [PATCH] bitbake.conf: use PACKAGE_ARCH instead of TARGET_ARCH in SDK_NAME

Quoted 19 lines · Martin Jansa

* also use weak assignment for SDK_NAME_PREFIX as suggested by khem
* PACKAGE_ARCH is not 100% right too, because such SDK image usually has few machine specific packages included (e.g. base-files, securetty, opkg configs) but those are not important for SDK users so it's better to have one SDK for whole e.g. armv7a-vfp-neon then 6 SDK for each machine which would work the same.
You can see diff between crespo and om-gta04 SDK here:
http://build.shr-project.org/shr-core-staging/031/sdk/oecore-i686-armv7a-vfp-neon-toolchain-efl-crespo-om-gta04.diff
Signed-off-by Martin Jansa <[email protected]>
---
meta/conf/bitbake.conf | 4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
meta/conf/bitbake.conf +0 -0
index 87bb71c..91f8397 100644

meta/conf/bitbake.conf PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}" · line 368

Quoted 7 lines

meta/conf/bitbake.conf +2 -2

@@ -364,8 +364,8 @@ PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
  # SDK variables,
  ##################################################################
 
-SDK_NAME_PREFIX = "oecore"
-SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TARGET_ARCH}"
+SDK_NAME_PREFIX ?= "oecore"
+SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${PACKAGE_ARCH}"

Why PACKAGE_ARCH over TUNE_ARCH?

-M

McClintock Matthew-B29882

2012-03-09 16:42 UTC #9 lore raw

Re: [PATCH] bitbake.conf: use PACKAGE_ARCH instead of TARGET_ARCH in SDK_NAME

Quoted 23 lines · Matthew McClintock

Quoted 22 lines · Martin Jansa
* also use weak assignment for SDK_NAME_PREFIX as suggested by khem
* PACKAGE_ARCH is not 100% right too, because such SDK image usually has few machine specific packages included (e.g. base-files, securetty, opkg configs) but those are not important for SDK users so it's better to have one SDK for whole e.g. armv7a-vfp-neon then 6 SDK for each machine which would work the same.
You can see diff between crespo and om-gta04 SDK here:
http://build.shr-project.org/shr-core-staging/031/sdk/oecore-i686-armv7a-vfp-neon-toolchain-efl-crespo-om-gta04.diff
Signed-off-by Martin Jansa <[email protected]>
---
meta/conf/bitbake.conf | 4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
meta/conf/bitbake.conf +0 -0
index 87bb71c..91f8397 100644
@@ -364,8 +364,8 @@ PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
  # SDK variables,
  ##################################################################
 

Quoted 6 lines

meta/conf/bitbake.conf PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}" · line 368
Quoted 4 lines
meta/conf/bitbake.conf +2 -2
-SDK_NAME_PREFIX = "oecore"
-SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TARGET_ARCH}"
+SDK_NAME_PREFIX ?= "oecore"
+SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${PACKAGE_ARCH}"
Why PACKAGE_ARCH over TUNE_ARCH?

Or rather TUNE_PKGARCH?

-M

Martin Jansa

author

2012-03-09 17:09 UTC #10 lore raw

Re: [PATCH] bitbake.conf: use PACKAGE_ARCH instead of TARGET_ARCH in SDK_NAME

Quoted 24 lines · On Fri, Mar 09, 2012 at 04:33:33PM +0000, McClintock Matthew-B29882 wrote:

Quoted 23 lines · Matthew McClintock
Quoted 22 lines · Martin Jansa
* also use weak assignment for SDK_NAME_PREFIX as suggested by khem
* PACKAGE_ARCH is not 100% right too, because such SDK image usually has few machine specific packages included (e.g. base-files, securetty, opkg configs) but those are not important for SDK users so it's better to have one SDK for whole e.g. armv7a-vfp-neon then 6 SDK for each machine which would work the same.
You can see diff between crespo and om-gta04 SDK here:
http://build.shr-project.org/shr-core-staging/031/sdk/oecore-i686-armv7a-vfp-neon-toolchain-efl-crespo-om-gta04.diff
Signed-off-by Martin Jansa <[email protected]>
---
meta/conf/bitbake.conf | 4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
meta/conf/bitbake.conf +0 -0
index 87bb71c..91f8397 100644
@@ -364,8 +364,8 @@ PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
  # SDK variables,
  ##################################################################
 

Quoted 8 lines

Quoted 6 lines
meta/conf/bitbake.conf PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}" · line 368
Quoted 4 lines
meta/conf/bitbake.conf +2 -2
-SDK_NAME_PREFIX = "oecore"
-SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TARGET_ARCH}"
+SDK_NAME_PREFIX ?= "oecore"
+SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${PACKAGE_ARCH}"
Why PACKAGE_ARCH over TUNE_ARCH?
Or rather TUNE_PKGARCH?

In
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/018543.html
I've said:

"And we should change TARGET_ARCH in SDK_NAME to PACKAGE_ARCH or TUNE_PKGARCH"

So why TUNE_ARCH/TUNE_PKGARCH over PACKAGE_ARCH?

I don't see the advantage, but if there is some I'll update it in v2.

Cheers,

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

McClintock Matthew-B29882

2012-03-09 17:15 UTC #11 lore raw

Re: [PATCH] bitbake.conf: use PACKAGE_ARCH instead of TARGET_ARCH in SDK_NAME

Quoted 38 lines · Martin Jansa

Quoted 24 lines · On Fri, Mar 09, 2012 at 04:33:33PM +0000, McClintock Matthew-B29882 wrote:
Quoted 23 lines · Matthew McClintock
Quoted 22 lines · Martin Jansa
* also use weak assignment for SDK_NAME_PREFIX as suggested by khem
* PACKAGE_ARCH is not 100% right too, because such SDK image usually has few machine specific packages included (e.g. base-files, securetty, opkg configs) but those are not important for SDK users so it's better to have one SDK for whole e.g. armv7a-vfp-neon then 6 SDK for each machine which would work the same.
You can see diff between crespo and om-gta04 SDK here:
http://build.shr-project.org/shr-core-staging/031/sdk/oecore-i686-armv7a-vfp-neon-toolchain-efl-crespo-om-gta04.diff
Signed-off-by Martin Jansa <[email protected]>
---
meta/conf/bitbake.conf | 4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
meta/conf/bitbake.conf +0 -0
index 87bb71c..91f8397 100644
@@ -364,8 +364,8 @@ PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
  # SDK variables,
  ##################################################################
 
Quoted 8 lines
Quoted 6 lines
meta/conf/bitbake.conf PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}" · line 368
Quoted 4 lines
meta/conf/bitbake.conf +2 -2
-SDK_NAME_PREFIX = "oecore"
-SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TARGET_ARCH}"
+SDK_NAME_PREFIX ?= "oecore"
+SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${PACKAGE_ARCH}"
Why PACKAGE_ARCH over TUNE_ARCH?
Or rather TUNE_PKGARCH?
In
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/018543.html
I've said:

Quoted 5 lines

"And we should change TARGET_ARCH in SDK_NAME to PACKAGE_ARCH or TUNE_PKGARCH"
So why TUNE_ARCH/TUNE_PKGARCH over PACKAGE_ARCH?
I don't see the advantage, but if there is some I'll update it in v2.

Well for powerpc (PACKAGE_ARCH) we have ppce500mc, ppce500v2, and ppce5500 (TUNEPKG_ARCH) and for powerpc64 we have ppc64e5500. This is what I would want my toolchain to convey - not sure what the best generic solution is.

-M

Martin Jansa

author

2012-03-15 07:32 UTC #12 lore raw

PATCH v2 1/1 bitbake.conf: use TUNE_PKGARCH instead of TARGET_ARCH in SDK_NAME

* also use weak assignment for SDK_NAME_PREFIX as suggested by khem
* TUNE_PKGARCH is not 100% right too, because such SDK image usually has few machine specific packages included (e.g. base-files, securetty, opkg configs) but those are not important for SDK users so it's better to have one SDK for whole e.g. armv7a-vfp-neon then 6 SDK for each machine which would work the same.
You can see diff between crespo and om-gta04 SDK here:
http://build.shr-project.org/shr-core/sdk/oecore-i686-armv7a-vfp-neon-toolchain-efl-crespo-om-gta04.diff

Signed-off-by Martin Jansa <[email protected]>

---
 meta/conf/bitbake.conf |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

meta/conf/bitbake.conf +2 -2

index 216da75..01fc52a 100644
@@ -365,8 +365,8 @@ PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
 # SDK variables, 
 ##################################################################
 
-SDK_NAME_PREFIX = "oecore"
-SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TARGET_ARCH}"
+SDK_NAME_PREFIX ?= "oecore"
+SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TUNE_PKGARCH}"
 SDKPATH = "/usr/local/${SDK_NAME_PREFIX}-${SDK_ARCH}"
 SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"

Signature · 1 line

1.7.8.5

Saul Wold

Applied

2012-04-27 20:59 UTC #13 lore raw

Re: [PATCHv2] bitbake.conf: use TUNE_PKGARCH instead of TARGET_ARCH in SDK_NAME

Quoted 19 lines · Martin Jansa

* also use weak assignment for SDK_NAME_PREFIX as suggested by khem
* TUNE_PKGARCH is not 100% right too, because such SDK image usually has few machine specific packages included (e.g. base-files, securetty, opkg configs) but those are not important for SDK users so it's better to have one SDK for whole e.g. armv7a-vfp-neon then 6 SDK for each machine which would work the same.
You can see diff between crespo and om-gta04 SDK here:
http://build.shr-project.org/shr-core/sdk/oecore-i686-armv7a-vfp-neon-toolchain-efl-crespo-om-gta04.diff
Signed-off-by Martin Jansa<[email protected]>
---
  meta/conf/bitbake.conf |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
meta/conf/bitbake.conf +0 -0
index 216da75..01fc52a 100644

meta/conf/bitbake.conf PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}" · line 372

Quoted 10 lines

meta/conf/bitbake.conf +2 -2

@@ -365,8 +365,8 @@ PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
  # SDK variables,
  ##################################################################
 
-SDK_NAME_PREFIX = "oecore"
-SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TARGET_ARCH}"
+SDK_NAME_PREFIX ?= "oecore"
+SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TUNE_PKGARCH}"
  SDKPATH = "/usr/local/${SDK_NAME_PREFIX}-${SDK_ARCH}"
  SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"

Merged into OE-Core

Thanks
Sau!