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

[Tom Rini <tom_rini@mentor.com>]

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

-- 
Tom Rini
Mentor Graphics Corporation