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

[Cui, Dexuan]

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