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

[Cui, Dexuan]

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
>> ......
>> 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.
Thanks for all the clarification!

>> 3) In gnu-config_20080123.bb's do_install, I don't understand this
>>     lines: here the "!=" should be "="? if [ "${BUILD_ARCH}" !=
>>         "${TARGET_ARCH}" ]; then sed -i -e
>>     's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize fi
> 
> This means it only applies for non-native packages. (native has
> BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
> with things like the nativesdk packages where bindir != "/usr/bin".
Thanks for the explanation!
My understanding about "non-native package" is target recipe (in this case bindir=/usr/bin)
and -nativesdk recipe.
gnu-config_20080123.bb doesn't have -nativesdk version(BBCLASSEXTEND doesn't
contain nativesdk), so looks the sed replacement is useless at present?


>> e.g. when building gnu-config-native for MACHINE qemux86 on a 32-bit
>> host,  BUILD_ARCH=TARGET_ARCH=i686-linux and the sed isn't invoked;
>> when building gnu-config, the sed will be invoked, but bindir is
>> just /usr/bin, so the replacement operation actually does nothing.
> 
> You can define a system where exec_prefix is "" and bindir is hence
> "/bin" when it wouldn't do nothing.
> 
>> And for gnu-config-native, I think we need do a
>> sed -i -e
>> 's,/usr/bin/perl,${STAGING_BINDIR_NATIVE}/perl-native/perl,g'
>> ${D}${bindir}/gnu-configize Correct? 
> 
> No, the whole point is to stop it seeing perl-native. Only perl itself
> and modules should be using perl-native.
So gnu-config-native should use perl-native-runtime(i.e., the system perl) and
shouldn't depend on perl-native.
Howeve, there is a sed replacement in gnu-config-native's do_install:
-e 's, at autom4te_perllibdir@,${datadir}/autoconf,g
and meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in is intened
to be run with "#! /usr/bin/env perl" -- this incurs some race conditions:
1) if perl-natvie does populate_sysroot later than
${STAGING_BINDIR_NATIVE}/gnu-configize is invoked, /usr/bin/perl is used
but perl-native's modules are used due to the "unshift @INC, $datadir" in gnu-configize.in.
This is just http://bugzilla.pokylinux.org/show_bug.cgi?id=941
2)  if perl-natvie does populate_sysroot earlier than the gnu-configize
is invokded, we don't meet bug 941.

The above is the current situation. If we install perl-native into its own
sysroot, in the gnu-configize, the system perl is always found and used,
and we always meet with bug 941.

How can we fix bug 941 then?

BTW: the 2 lines at the beginning of gnu-configize.in is suspicious:
eval 'case $# in 0) exec /usr/bin/perl -S "$0";; *) exec /usr/bin/perl -S "$0" "$@";; esac'
    if 0;
I'm new to the synax of perl, but I believe the string after the "eval" is
not executed due to "if 0".
Can we remove the 2 lines?

> 
>> 4) My last commit of the top 5 commits is a chaos... I'm trying to
>> replace every "DEPENDS on perl-native" with "inherit perlnative".
>> I'm now stuck in fixing the build issues for libxml-parser-perl and
>> libxml-parser-perl-native. 
>> I don't know how to fix get_perl_version and perl_get_libdirs in
>> cpan-base.bbclass -- for libxml-parser-perl-native, I have to manage
>> to add a "/perl-native" into STAGING_LIBDIR and libdir, but for
>> libxml-parser-perl, I can't change STAGING_LIBDIR and libdir. Can you
>> please help me out?
> 
> I'd suggest splitting this into two steps:
> 
> a) Check through all perl-native references and correct the ones that
>    should be perl-native-runtime.
> b) Replace all remaining perl-native references with the class
>    dependency.
Ok, I'm checking all the references.

> In step a), gnu-config would have a dependency on perl-native-runtime
> so wouldn't use the perlnative class.
Please see my above reply.

> Just for reference, using perl-native-runtime means that someone can
> remove it from ASSUME_PROVIDED and provide a version of it themselves
> if they so wish (using perl-native or otherwise).
> 
> I suspect you'll still have the libxml-parser-perl problem but lets
> take this one step at a time! :)
I'll continue to try to fix this. :-)

Richard, thanks a lot for your help!

-- Dexuan