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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote:
> (Sorry for my delay for the task as I was working on other bugs...)
> 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.

> 2) In poky, I see many places hardcodedly use the system
> perl(i.e., /usr/bin/perl) explicitly or implicitly(e.g,
> meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in
> contains /usr/bin/perl; another example,  in perl-5.12.3's source
> code, Cross/generate_config_sh also contains #!/usr/bin/perl). Should
> we fix all of them?

Most of these should be generated locations and I think this is fine
since most of these are "perl-native-runtime" uses and its fine to use
the build system perl.

>    And what's the relationship between the system perl and
> perl-native? Since perl-native is not less functional than the system
> perl, will we eliminate the system perl as a prerequisite to bitbake
> in future?

No, I think you have this backwards. The intent is to have
"perl-native-runtime" denoting a requirement on the build system perl
and "perl-native" being a perl that exactly the same as the target perl
for cross purposes.

> 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".

> 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.

> 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.

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

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! :)

Cheers,

Richard