On Tue, Jul 24, 2018 at 12:22 AM, Krzysztof Taborski <taborskikrzysz...@gmail.com> wrote: > Hello, > Example recipe (recipe.bb for example): > """ > LICENSE="CLOSED" > > RDEPENDS_${PN} = "perl-module-file-glob" > > BBCLASSEXTEND = "native nativesdk" > do_install() { > install -d ${D}/${bindir} > echo "my perl script" > ${D}/${bindir}/recipe.pl > } > inherit perlnative > "" > > When my patch is removed and I will call: "'bitbake recipe-native". > Then I have dependency: > recipe-native -> perl (target version) > This is not correct, that native recipe has dependency to target recipe.
There are two parts to this issue. First, the dependency between recipe-native and perl is certainly a bug and your fix for that in the perl recipe looks good, ie setting PACKAGES_DYNAMIC += "^perl-module-.*(?<!\-native)$" However, after making that first fix, although the recipe-native -> perl dependency will be gone, trying to build your recipe-native should now generate a build failure - bitbake will correctly report that nothing provides a package called "perl-module-file-glob-native". The question is really how to fix that new build failure. One approach (the approach you took - the second part of your patch) is to update the perl-native recipe so that pretends to provide packages named "perl-module-XXX-native". The alternative approach is to explicitly set RDEPENDS for the -native build of your recipe to over-ride the false dependency added by the native class dependency renaming e.g. RDEPENDS_${PN}_class-native = "perl-native" That second approach is basically what the autoconf recipe does to solve a similar problem: http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/autoconf/autoconf.inc?h=sumo As to which is the more "correct" approach, I'm not really sure. Opinions welcome... > When I called (bitbake recipe-native -g) I can find: > "recipe-native" -> "perl" > in recipe-depends.dot > > This was my original problem. Please correct me, if missed something. > > usage of += with an over-ride - I've just copied it from nativesdk > over-ride, which was already in perl recipe. > > > Best regards, > Krzysztof Taborski > > 2018-07-23 19:23 GMT+02:00 Andre McCurdy <armccu...@gmail.com>: >> >> On Mon, Jul 23, 2018 at 5:57 AM, Krzysztof Taborski >> <taborskikrzysz...@gmail.com> wrote: >> > Change was already merged: >> > >> > http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools?id=7dd9772eca6df52db09b65537fdf689f1aa3fd8f >> > >> > Is your request still valid? >> >> Yes, although the change was merged, it's not clear that it was correct. >> >> Native recipes aren't split into packages, so there are no -native >> versions of the perl modules. If you have a recipe which depends on >> "perl-module-XXX-native" it's likely a bug in that recipe - not in >> perl-native. >> >> What recipe did you find which depends on a -native version of a perl >> module? >> >> > 2018-07-09 21:40 GMT+02:00 Andre McCurdy <armccu...@gmail.com>: >> >> >> >> On Wed, May 9, 2018 at 7:16 AM, taborskikrzysztof >> >> <taborskikrzysz...@gmail.com> wrote: >> >> > Can I request review? >> >> > -------- Oryginalna wiadomość -------- >> >> > Od: Krzysztof Taborski <taborskikrzysz...@gmail.com> >> >> > Data: 08.05.2018 18:46 (GMT+01:00) >> >> > Do: openembedded-core@lists.openembedded.org >> >> > DW: Krzysztof Taborski <taborskikrzysz...@gmail.com> >> >> > Temat: [meta-oe][PATCH] perl: native modules will not trigger build >> >> > perl >> >> > for >> >> > target. >> >> > >> >> > Currently building perl-native modules triggers >> >> > build perl for target due to PACKAGES_DYNAMIC regex. >> >> > >> >> > This commit will cause, that perl native modules will >> >> > trigger perl-native build. >> >> >> >> Can you give an example of how to reproduce the problem? >> >> >> >> > Signed-off-by: Krzysztof Taborski <taborskikrzysz...@gmail.com> >> >> > --- >> >> > meta/recipes-devtools/perl/perl-native_5.24.1.bb | 2 ++ >> >> > meta/recipes-devtools/perl/perl_5.24.1.bb | 2 +- >> >> > 2 files changed, 3 insertions(+), 1 deletion(-) >> >> > >> >> > diff --git a/meta/recipes-devtools/perl/perl-native_5.24.1.bb >> >> > b/meta/recipes-devtools/perl/perl-native_5.24.1.bb >> >> > index a9ab17d16c..71f45890b0 100644 >> >> > --- a/meta/recipes-devtools/perl/perl-native_5.24.1.bb >> >> > +++ b/meta/recipes-devtools/perl/perl-native_5.24.1.bb >> >> > @@ -135,3 +135,5 @@ EOF >> >> > >> >> > # Fix the path in sstate >> >> > SSTATE_SCAN_FILES += "*.pm *.pod *.h *.pl *.sh" >> >> > +PACKAGES_DYNAMIC_class-native += "^perl-module-.*native$" >> >> >> >> This usage of += with an over-ride is not correct. >> >> >> >> However, regardless of that, was this change actually needed? >> >> >> >> If you know of a -native recipe which depends on a >> >> perl-module-XXX-native package then it's probably a bug in the -native >> >> recipe. Having perl-native pretend to provide perl-module packages >> >> probably isn't the right solution. >> >> >> >> > diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb >> >> > b/meta/recipes-devtools/perl/perl_5.24.1.bb >> >> > index 53a426289a..4c6a71082f 100644 >> >> > --- a/meta/recipes-devtools/perl/perl_5.24.1.bb >> >> > +++ b/meta/recipes-devtools/perl/perl_5.24.1.bb >> >> > @@ -339,7 +339,7 @@ python split_perl_packages () { >> >> > d.setVar(d.expand("RRECOMMENDS_${PN}-modules"), ' >> >> > '.join(packages)) >> >> > } >> >> > >> >> > -PACKAGES_DYNAMIC += "^perl-module-.*" >> >> > +PACKAGES_DYNAMIC += "^perl-module-.*(?<!\-native)$" >> >> > PACKAGES_DYNAMIC_class-nativesdk += "^nativesdk-perl-module-.*" >> >> >> >> This usage of += with an over-ride is not correct. >> >> >> >> > RPROVIDES_perl-lib = "perl-lib" >> >> > -- >> >> > 2.13.6 >> >> > >> >> > >> >> > -- >> >> > _______________________________________________ >> >> > Openembedded-core mailing list >> >> > Openembedded-core@lists.openembedded.org >> >> > http://lists.openembedded.org/mailman/listinfo/openembedded-core >> >> > >> > >> > >> > >> > >> > -- >> > Pozdrawiam, >> > Krzysiek Taborski > > > > > -- > Pozdrawiam, > Krzysiek Taborski -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core