Tom Rini wrote: > On 05/05/2011 03:34 PM, Richard Purdie wrote: >> On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote: >>> Recently I have been looking into it and I've made some commits (the >>> top 5 small commits) in >>> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dcui/master_perl-native >>> BTW: the work is not done completely as some recipes don't build >>> with the changes. Please have a look anyway to see if I'm in the >>> correct direction. >>> >>> However, I've got some difficulties and hope to get your help: >>> 1) As you said, after we install perl-native into its own >>> directory, >>> any recipe not depending on perl-native doesn't see >>> ${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily. >>> However, if we keep the current code, what's the bad consequence if >>> the recipe not depending on perl-native does see perl of >>> perl-native? >>> looks no? >> >> We have an assumption that perl is already on the system we're >> building on. Perl is a relatively stable language with defined >> compatibility and interoperability. Most recipes are therefore fine >> using perl from the build system directly and don't need >> perl-native. I think we defined a special name for the build system >> perl (perl-native-runtime?). Better names are welcome but we should >> ensure we use the right dependency in the right places. >> >> The time to use perl-native instead of perl-native-runtime is where >> any perl module is being built, perl itself is being built or >> anything that has an explicit dependency on the perl version present. > > The problem that follows up is that once we have built any sort of > perl-native we then have to go and be really really really careful > that nothing that's not (a) target perl (b) some perl module we built > and need to run uses it. Otherwise we run into the problems I think > that've been hit here. Problems like this are why for OE I just made > perl-native be the perl we rely on for everything. > > I know we talked about this before and you had a strong desire to try > and do something else but I think this shows maybe we need to try > going down the perl-native everywhere path first and then see if we > can't do something different. Hi Tom, do you mean we should try to use perl-native first and try the best to avoid using /usr/bin/perl?
Thanks, -- Dexuan _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core