Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-10 Thread Tom Rini
On 06/09/2011 01:08 AM, Richard Purdie wrote: On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote: On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote: On 06/02/2011 09:35 AM, Richard Purdie wrote: On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote: Even if we're using the sstate cache

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-10 Thread Tom Rini
On 06/09/2011 01:04 AM, Richard Purdie wrote: On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote: On 06/02/2011 09:35 AM, Richard Purdie wrote: On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote: Even if we're using the sstate cache from /foo/oecore/tmp over in /bar/oecore/tmp (and

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-09 Thread Richard Purdie
On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote: On 06/02/2011 09:35 AM, Richard Purdie wrote: On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote: Even if we're using the sstate cache from /foo/oecore/tmp over in /bar/oecore/tmp (and /foo/oecore/tmp is rm -rf'd) ? Since we've got a

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-09 Thread Richard Purdie
On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote: On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote: On 06/02/2011 09:35 AM, Richard Purdie wrote: On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote: Even if we're using the sstate cache from /foo/oecore/tmp over in

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-02 Thread Cui, Dexuan
Tom Rini wrote: On 06/01/2011 01:05 PM, Phil Blundell wrote: On Wed, 2011-06-01 at 12:39 -0700, Tom Rini wrote: Maybe race isn't quite the right word. But recipe A depends on lib$something-perl-native, and brings in perl-native. It also checks for perl in its auto-foo and finds our perl.

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-02 Thread Richard Purdie
On Wed, 2011-06-01 at 13:59 -0700, Tom Rini wrote: On 06/01/2011 01:45 PM, Phil Blundell wrote: On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote: What falls down in this case is that once perl-native is built (and in our PATH), if it's a different version than system-wide perl, stuff

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-02 Thread Tom Rini
On 06/02/2011 07:06 AM, Richard Purdie wrote: On Wed, 2011-06-01 at 13:59 -0700, Tom Rini wrote: On 06/01/2011 01:45 PM, Phil Blundell wrote: On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote: What falls down in this case is that once perl-native is built (and in our PATH), if it's a

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-02 Thread Phil Blundell
On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote: But help2man is just the easy/common case. Heck, it _may_ blow up even with the host help2man instead of help2man-native, if a recipe uses system-wide help2man and perlnative.bbclass. The root problem (again, from memory) is that since we

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-02 Thread Tom Rini
On 06/02/2011 07:37 AM, Phil Blundell wrote: On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote: But help2man is just the easy/common case. Heck, it _may_ blow up even with the host help2man instead of help2man-native, if a recipe uses system-wide help2man and perlnative.bbclass. The root

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-02 Thread Richard Purdie
On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote: On 06/02/2011 07:37 AM, Phil Blundell wrote: On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote: But help2man is just the easy/common case. Heck, it _may_ blow up even with the host help2man instead of help2man-native, if a recipe uses

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-02 Thread Tom Rini
On 06/02/2011 09:35 AM, Richard Purdie wrote: On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote: On 06/02/2011 07:37 AM, Phil Blundell wrote: On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote: But help2man is just the easy/common case. Heck, it _may_ blow up even with the host help2man

[OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-01 Thread Dexuan Cui
Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in the PATH when bitbake is running. This can cause some race conditions: many places detecting perl from PATH can't make sure which path will be used as this

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-01 Thread Richard Purdie
Hi Dexuan, On Wed, 2011-06-01 at 21:18 +0800, Dexuan Cui wrote: Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in the PATH when bitbake is running. This can cause some race conditions: many places

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-01 Thread Richard Purdie
On Wed, 2011-06-01 at 10:17 -0700, Tom Rini wrote: On 06/01/2011 06:18 AM, Dexuan Cui wrote: Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in the PATH when bitbake is running. This can cause some

Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

2011-06-01 Thread Phil Blundell
On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote: What falls down in this case is that once perl-native is built (and in our PATH), if it's a different version than system-wide perl, stuff starts failing on version mis-match. I think that's the bit that I'm not properly understanding. Which