Created attachment 4356 [details] sample user of cpan_build.bbclass: libio-stty-perl_0.03.bb As explained in IRC today: <pespin_> hi, I'm using a recipe which inherits cpan_build.bbclass but it fails at configure time with: "Can't locate Module/Build.pm in @INC (you may need to install the Module::Build module)" <pespin_> I'm indeed unable to find the Build.pm file in any sysroot <pespin_> shouldn't the bbclass take care to install that one automatically? (using cpan.bbclass? I don't have much perl knowledge) <pespin_> as far as I understand from cpan_build.bbclass, Module::Build used to be installed by perl-native but at some point it was dropped. <pespin_> But it seems nobody provided a new recipe to install it from cpan in cpan_build.bbclass <pespin_> here's a sample recipe using cpan_build if some else with more perl knowledge wants to give it a try: https://paste.debian.net/1037170/ <pespin_> because it seems no recipe in poky uses cpan_build.bbclass, that probably explains why it's broken? <pespin_> in here it explains dropping Module::Build from perl core: http://www.dagolden.com/index.php/2140/paying-respect-to-modulebuild/ <smurray> pespin_: it looks like the meta-perl layer in meta-openembedded has libmodule-build-perl, and the one cpan_build user in there add DEPENDS += "libmodule-build-perl-native" to have things work <pespin_> smurray, shouldn't that be in poky or oe-core then? otherwise the bbclass is broken <smurray> pespin_: It does seem a bit odd, but if there are no users in oe-core, I suspect it's fallen through the cracks <pespin_> smurray, not sure if the one in meta-openembedded works though, since libmodule-build-perl inherits cpan_build.... <pespin_> I think that libmodule-build-perl.bb should be changed to use cpan instead of cpan_build. Then revert this commit in poky: https://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/cpan_build.bbclass?id=304ebe1fa2b05f62a15882095317044fd29c4c8d
Richard requests that we move a single perl recipe from meta-oe to oe-core to test for this type of failure. It can be libio-stty-perl_0.03.bb or perhaps another recipe that also fails would be a better choice. By adding a single recipe, we'll avoid future regressions.
Here's a proposed set of 3 patches to poky that allows me to build libio-stty-perl using cpan_build. You can find it in branch pespin/cpan of my poky.git fork in github [1]. The branch is on top of latest pyro, since it's the poky version I'm currently using, but as far as I can see the issues are the same with master. Please give them a review and some testing and provide feedback or fix them as needed. The changes I did to cpan.bbclass may break other perl recipes, I didn't try building other ones. [1] https://github.com/pespin/poky/commits/pespin/cpan
I agree with Randy in Comment #1 that we need to have a recipe in oe-core that depends on libmodule-build-perl (and therefore moving libmodule-build-perl to oe-core will make sense).
We should also have a test in oeqa that verifies the cpan_build.bbclass is functional.
libmodule-build-perl itself inherits cpan_build, so that recipe alone might be enough. I am currently fighting ptests for libmodule-build-perl (it expects to run all tests from blib, rather than vendor_perl). All other lib<foo>-perl modules in oe-core have ptest enabled and passing.
Submitted as part of: https://patchwork.openembedded.org/series/18187/ The actual moving of the recipe was trivial, but fixing perl-rdepends.txt, especially with ptest enabled, was a big chore. Nine of the tests fail (~5 are known failing upstream, the others are non-obvious cause: "build_params" missing and OUTPUT typemap issues). We still need to decide if we need another recipe that inherits cpan_build in oe-core. I would also prefer oeselftest, but not sure how to approach that off the top of my head. Perhaps use the Simple example the libmodule-build-perl builds as part of its tests. Or perhaps the ptesting is enough?
I think with basic ptests we get at least some coverage and that helps address some of my concerns that I had when this was originally discussed. A simple module that tests it would still be nice to have but not essential.
I am going to mark this as resolved. The patches were merged.