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

[Tom Rini <tom_rini@mentor.com>]

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 problem (again,
>> from memory) is that since we modify PERL5LIB and so on, when we do
>> that, we've opened ourselves up for system-wide perl trying to use
>> perl-native's stuff.
> 
> Ah right, I think I see what you're getting at now.
> 
> If we've got a clean separation between perl-native and host perl,
> though, can't we now just eliminate all of that futzing with PERL5LIB in
> cpan.bbclass and such like places?  perl-native already knows how to
> look in the right places within the sysroot for its modules so there
> should be no need for anything else to be overriding it.

Well, my question is, does it, really?  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 create_wrapper around perl and
perl${PV} it should be I suppose (or is easily added there), but I'd
feel a lot better with some testing of the above case (and the updates
to cpan*bbclass).

-- 
Tom Rini
Mentor Graphics Corporation