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

[Tom Rini]

On 06/09/2011 01:08 AM, Richard Purdie wrote:
> On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote:
>> On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
>>> On 06/02/2011 09:35 AM, Richard Purdie wrote:
>>>> On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
>>>>>   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.
>>
>> The first three of these are all about the *target* perl location and I
>> think we still need them due the mess that perl's build system is. With
>> the patch series in question they won't actually point at perl-native in
>> the target case and they are only really used for cross compiling
>> purposes.
>>
>> PERLHOSTLIB is used by the target perl when cross compiling to find
>> native .so files. perl-native will always be present at this point and
>> again, it seems like a valid use case.
>>
>> Summary is that I don't think perl-native is broken in any way but we do
>> need those variables.
>>
>>> - 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.
>>
>> I'm confused by this test cycle. What do you mean by "build
>> perl-native's full sstate cache"?
>>
>> I suspect you've asking for some partial sstate cache to be shared
>> between two builds?
>>
>> Put simpler, you probably want:
>>
>> in tmp0 "bitbake perl-native"
>> in tmp1, different location to tmp0, "bitbake core-image-sato" but
>> sharing the same sstate cache
> 
> I meant to add that tmp0 should be renamed before this second step so if
> there are hardcoded references in any of the sstate packages they
> couldn't find anything in tmp0 as it would no longer exist.

Yes, this is what I'm asking for.

-- 
Tom Rini
Mentor Graphics Corporation