Tom Rini wrote: > On 06/01/2011 01:05 PM, Phil Blundell wrote: >> On Wed, 2011-06-01 at 12:39 -0700, Tom Rini wrote: >>> Maybe race isn't quite the right word. But recipe A depends on >>> lib$something-perl-native, and brings in perl-native. It also >>> checks >>> for perl in its auto-foo and finds our perl. It now also uses our >>> perl when it wants a host perl and all of the potential bad things >>> happen, yes? >> >> What are the circumstances in which it would want a host perl? I >> don't quite understand the issue here. Surely anything that the >> host perl can do, perl-native plus some combination of >> libfoo-perl-native can also do, right? > > So, here's the two things going on: > - In some cases (libfoo-perl-native) we need to install various perl > modules in order to build other target apps. This is the cpan case, > iirc. We don't currently (and can't?) just play whatever games perl > would like to do to use system-wide perl and a local to TMPDIR cpan > directory. We instead go down the path of having perl-native. > - In order to build perl for the target we need to have the same perl > version available for use. > > What we do in oe-core (and oe.dev, historically) is provide > perl-native > for both of these cases. What falls down in this case is that once > perl-native is built (and in our PATH), if it's a different version > than system-wide perl, stuff starts failing on version mis-match. > The patch series here fixes that by saying stuff must opt-in to > having perl-native > be in PATH rather than just system-wide perl. What I'm saying is that > while in oe-core nothing falls down here (since nothing that gets > perl-native also tries to just run 'perl') meta-oe is or will have > failures. > > Unfortunately I don't have the test cases that drove me to make oe.dev > like it is handy but I have a feeling that if we go down this path it > won't be the last we see of the problem, but it might well pop up > again. > > There is another option here, which is to make perl-native be > perl-cross, live in its own special directory and figure out how to > make > a TMPDIR-specific cpan repository available for use by system-wide > perl.
Hi Tom, Thank you very much for the detailed explanation! However I'm actually new to cpan and know few about the history of that in oe.dev, so I'm not sure I know enough about the background to make a proper decision now. I suppose Richard would comment here. :-) Thanks, -- Dexuan _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
