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

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

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.

> 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
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core