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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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

Is that what you're thinking?

FWIW, I've been running locally with the patch series and I think I'd
like to merge it. If there are issues we can address them as and when
they're identified...

Cheers,

Richard