On 05/10/2011 07:09 AM, Cui, Dexuan wrote: > 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?
Yes. Roughly, make automake-native/autoconf-native depend on perl-native and perform a few changes to libtool-native and gnu-config-native to make sure it uses /usr/bin/env perl. -- Tom Rini Mentor Graphics Corporation _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
