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

[Tom Rini <tom_rini@mentor.com>]

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 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?
> 
> If it doesn't it really does need to get fixed. I've not seen any
> evidence this has been the problem but it still could be.

I agree it needs to be fixed, yes.  One way or another...

>>   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).
> 
> I only took the perl-native DEPENDS patch on the condition this gets
> fixed properly. The patches that are there look to do that, at least for
> OE-Core. If there are further issues we're going to have to take them as
> they arise as I have an objection to crippling the build dependencies
> because perl is broken. Really this could use some TLC from someone with
> experience in the area...

Well, I guess I'd boil down what I said above into a request like this
for v3:
- Modify cpan.bbclass to NOT set PERL_INC / PERL_LIB / PERL_ARCHLIB /
PERLHOSTLIB.
- In /scratch/oecore/tmp0 build the images that were built for v1
- In /scratch/oecore/tmp1 build perl-native's full sstate cache.
- Keep the sstate cache from tmp1 and otherwise rm -rf tmp1.
- In /scratch/oecore/tmp2 using the sstate from tmp1, build the same
images that were built for tmp0.

If all of that works, I think we can call this safe enough for now and
possibly even really fixed, while we have someone actively kicking
around the recipes in question.

-- 
Tom Rini
Mentor Graphics Corporation