Re: [PATCH 37/58] gnu-config-native: add dependency on perl-native

[Tom Rini <tom_rini@mentor.com>]

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