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

[Tom Rini <tom_rini@mentor.com>]

On 06/01/2011 10:56 AM, Richard Purdie wrote:
> 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?

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.  It now also uses our perl
when it wants a host perl and all of the potential bad things happen, yes?

-- 
Tom Rini
Mentor Graphics Corporation