[gentoo-dev] new eclass proposal, perl-mb-tiny.eclass

[Kent Fredric]

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