Presently, in tree, for perl modules, there's a generic perl-module.eclass This has been OK for the most part, because the assumptions it has made have often been true.
For instance, perl-module.eclass thinks that if a file exists called Build.PL, that it will be using Module::Build, so it uses a series of specific ways of invoking that file, and performs a few QA warnings if you don't depend on module build. Previously, people figured an explicit dependency on Module::Build was excessive, because it was shipped as part of a standard Perl installation. However, Perl upstream are changing this, and will stop shipping Module::Build with perl in a future release, so things that presently need Module::Build to work *MUST* depend on it. Additionally, there's a newcommer on the field, *Module::Build::Tiny*, which has a mostly compatible interface, but is rather different under the hood, and things that need it to work MUST depend on it in order to perform *src_configure* However, as Module::Build::Tiny also uses Build.PL, we can no longer rely on that files existence as an indicator of the toolchain that is required. And to add insult to injury, the way we currently invoke Build.PL does *NOT*work when Build.PL is Module::Build::Tiny The *ONLY *safe way to determine what tooling a distribution needs is by looking at *META.yml* or *META.json* within a perl distribution, and looking for the *configure.requires* dependencies. But this is hardly something that can be done at runtime, and the very best we can do without having a seperate ebuild is a special magic variable that controls behaviour of *perl-module.eclass* But thats a poor design approach, using conditionals is a poor mans polymorphism. It seems much more sane to have an *.eclass* per perl-toolchain required, and then we can just handle the difference in behaviour by changing the inherit line. For perl distributions that inherently seem to support multiple ways of being built, we as downstream should pick one and force that method in the ebuild. Now, I'm not the best eclass author, I've given my approach to it here: https://github.com/gentoo-perl/perl-experimental/blob/master/eclass/perl-mb-tiny.eclass Its not perfect yet, and the documentation is wrong. It bases itself on the present perl-module.eclass and overrides everything applicable to focus on the task of building Module::Build::Tiny based distributions. This is an early query to the ML to get feedback on the general approach I've taken, and get an idea of whether I'm heading in the right direction or not. I would also be thinking about creating perl-mb.eclass and perl-eumm.eclass , for the 2 other dominant toolkits at this time, and then moving to transition packages that use perl-module.eclass to one of the 3. ( This is really just a move to apply the method we presently use for non-perl packages to perl packages, for instance, we don't autodetect during src_configure whether a gentoo package uses cmake or autoconf, that would just be silly, we do the smart thing and have an eclass for cmake, and an eclass for autoconf ) If somebody else knows what they're doing here and can contribute a better version of perl-mb-tiny.eclass, that'd be cool too =) -- Kent
