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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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 race conditions: many places detecting perl from PATH
> > can't make sure which path will be used as this depends on when perl-native's
> > populate_sysroot is finished, e.g., automake-native and autoconf-native could
> > use perl-native-runtime while gnu-config-native could use perl-native and
> > this inconsistent usages can cause trouble, e.g., bug 941.
> > 
> > And, as RP suggested, "the time to use perl-native instead of
> > perl-native-runtime is where any perl module is being built, perl itself is
> > being built or anything that has an explicit dependency on the perl version
> > present".
> > 
> > So I made the following changes to try to address the aboves issues:
> > 1) populate perl-native into its own directory so it won't appear in PATH
> > by default, and add perlnative.bbclass for these recipes that really depend
> > on perl-native;
> > 2) check all perl-native references and correct the ones that should be
> > perl-native-runtime;
> > 3) fix any building issues due to the new location of perl-native,
> > especially cpan and cpan-base .bbclass.
> > 
> > With the changes, bug 941 doesn't appear.
> > 
> > Tests I did are:
> > I tried "bitbale core-image-sato-sdk and meta-toolchain-gmae" in x86_32 and
> > x86_64 Ubuntu hosts and everything seems building fine.
> 
> How does this work (by which I mean, test some please :)) with meta-oe
> where we have (or will have soon) a lot of perl module recipes?  My
> concern is that we've just moved the race around a bit and we'll hit
> this somewhere else where we both really need "perl-native" (since we
> need some cpan stuff we've built) and also mangle in the perl we found
> in PATH into some scripts...

Anything building or using perl modules should be inheriting the
perlnative class. This adds the dependency on perl-native and the
appropriate PATH entry. Where is the race?

Cheers,

Richard