From: Joshua Lock <josh@linux.intel.com>
To: openembedded-devel@lists.openembedded.org
Subject: [PATCH] Maintain compatability with Python 2.4
Date: Tue, 01 Jun 2010 15:43:36 +0100 [thread overview]
Message-ID: <1275403416.2955.87.camel@localhost.localdomain> (raw)
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
Hi,
I just found this patch lying around, I forgot to submit it here.
A user contacted me about requiring Python 2.5 features in
relocatable.bbclass when OE claims Python 2.4 support.
I wrote them this patch and haven't heard any complaints back so assume
it works as intended, however I haven't tested it much myself.
When I raised the Python 2.4 vs 2.5 issue a while back it seems the
consensus was to stick to 2.4 support as RHEL still uses it.
Anyone care to merge?
Thanks,
Joshua
--
Joshua Lock
Intel Open Source Technology Centre
[-- Attachment #2: 0001-relocatable.bbclass-don-t-use-Python-2.5-features.patch --]
[-- Type: text/x-patch, Size: 3346 bytes --]
From 72399a3064367c92fcb7fe832adca289de0c10b2 Mon Sep 17 00:00:00 2001
From: Joshua Lock <josh@linux.intel.com>
Date: Mon, 10 May 2010 17:01:35 +0100
Subject: [PATCH] relocatable.bbclass: don't use Python 2.5 features
str.partition() is a "new" method for Python 2.5, as we claim Pyhton 2.4 or
above is required in the wiki we shouldn't use methods which aren't available
in Python 2.4.
This patch adds a (horrible) method, string_after() to replace the use of
str.partition()
Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
classes/relocatable.bbclass | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/classes/relocatable.bbclass b/classes/relocatable.bbclass
index eb5b9e6..cb82315 100644
--- a/classes/relocatable.bbclass
+++ b/classes/relocatable.bbclass
@@ -3,6 +3,11 @@ SYSROOT_PREPROCESS_FUNCS += "relocatable_binaries_preprocess"
CHRPATH_BIN ?= "chrpath"
PREPROCESS_RELOCATE_DIRS ?= ""
+def string_after(target, split):
+ target = target.strip().lstrip()
+ tmp = target[target.rfind(split):len(target)]
+ return tmp[len(split):len(target)]
+
def process_dir (directory, d):
import subprocess as sub
import stat
@@ -44,7 +49,7 @@ def process_dir (directory, d):
continue
# Throw away everything other than the rpath list
- curr_rpath = err.partition("RPATH=")[2]
+ curr_rpath = string_after(err, "RPATH=")
#bb.note("Current rpath for %s is %s" % (fpath, curr_rpath.strip()))
rpaths = curr_rpath.split(":")
new_rpaths = []
@@ -55,15 +60,12 @@ def process_dir (directory, d):
# If the rpath shares a root with base_prefix determine a new dynamic rpath from the
# base_prefix shared root
if rpath.find(basedir) != -1:
- depth = fpath.partition(basedir)[2].count('/')
- libpath = rpath.partition(basedir)[2].strip()
+ depth = string_after(fpath, basedir).count('/')
+ libpath = string_after(rpath, basedir).strip()
# otherwise (i.e. cross packages) determine a shared root based on the TMPDIR
- # NOTE: This will not work reliably for cross packages, particularly in the case
- # where your TMPDIR is a short path (i.e. /usr/poky) as chrpath cannot insert an
- # rpath longer than that which is already set.
else:
- depth = fpath.rpartition(tmpdir)[2].count('/')
- libpath = rpath.partition(tmpdir)[2].strip()
+ depth = string_after(rpath, tmpdir).count('/')
+ libpath = string_after(rpath, tmpdir).strip()
base = "$ORIGIN"
while depth > 1:
@@ -74,7 +76,7 @@ def process_dir (directory, d):
# if we have modified some rpaths call chrpath to update the binary
if len(new_rpaths):
args = ":".join(new_rpaths)
- #bb.note("Setting rpath for %s to %s" %(fpath,args))
+ #bb.note("Setting rpath for %s to %s" %(fpath, args))
sub.call([cmd, '-r', args, fpath])
if perms:
--
1.6.6.1
reply other threads:[~2010-06-01 14:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1275403416.2955.87.camel@localhost.localdomain \
--to=josh@linux.intel.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox