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

[Cui, Dexuan]

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.
Actually this doesn't work even without my patch series?
i.e., without my patch series,
1) I "bitbake perl-native" in /poky.git/build/;
2) mv /poky.git/build /poky.git/build.bak;
3) in /poky.git/build2/, modify the conf/local.conf to set SSTATE_MIRRORS to point to /poky.git/build.bak/sstate-cache/, and "bitbake sgmlspl-native" would fail in do_compile:
"Can't locate ExtUtils/Command.pm in @INC (@INC contains: /poky.git/build/tmp/sysroots/i686-linux/usr/lib/perl/5.12.3 /poky.git/build/tmp/sysroots/i686-linux/usr/lib/perl/5.12.3 /poky.git/build/tmp/sysroots/i686-"linux/usr/lib/perl/5.12.3"
Is this an existing bug? 

Thanks,
-- Dexuan