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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core