1 |
Presently, in tree, for perl modules, there's a generic perl-module.eclass |
2 |
|
3 |
This has been OK for the most part, because the assumptions it has made |
4 |
have often been true. |
5 |
|
6 |
For instance, perl-module.eclass thinks that if a file exists called |
7 |
Build.PL, that it will be using Module::Build, so it uses a series of |
8 |
specific ways of invoking that file, and performs a few QA warnings if you |
9 |
don't depend on module build. |
10 |
|
11 |
Previously, people figured an explicit dependency on Module::Build was |
12 |
excessive, because it was shipped as part of a standard Perl installation. |
13 |
|
14 |
However, Perl upstream are changing this, and will stop shipping |
15 |
Module::Build with perl in a future release, so things that presently need |
16 |
Module::Build to work *MUST* depend on it. |
17 |
|
18 |
Additionally, there's a newcommer on the field, *Module::Build::Tiny*, |
19 |
which has a mostly compatible interface, but is rather different under the |
20 |
hood, and things that need it to work MUST depend on it in order to perform |
21 |
*src_configure* |
22 |
|
23 |
However, as Module::Build::Tiny also uses Build.PL, we can no longer rely |
24 |
on that files existence as an indicator of the toolchain that is required. |
25 |
|
26 |
And to add insult to injury, the way we currently invoke Build.PL does |
27 |
*NOT*work when Build.PL is Module::Build::Tiny |
28 |
|
29 |
The *ONLY *safe way to determine what tooling a distribution needs is by |
30 |
looking at *META.yml* or *META.json* within a perl distribution, and |
31 |
looking for the *configure.requires* dependencies. |
32 |
|
33 |
But this is hardly something that can be done at runtime, and the very best |
34 |
we can do without having a seperate ebuild is a special magic variable that |
35 |
controls behaviour of *perl-module.eclass* |
36 |
|
37 |
But thats a poor design approach, using conditionals is a poor mans |
38 |
polymorphism. |
39 |
|
40 |
It seems much more sane to have an *.eclass* per perl-toolchain required, |
41 |
and then we can just handle the difference in behaviour by changing the |
42 |
inherit line. |
43 |
|
44 |
For perl distributions that inherently seem to support multiple ways of |
45 |
being built, we as downstream should pick one and force that method in the |
46 |
ebuild. |
47 |
|
48 |
Now, I'm not the best eclass author, I've given my approach to it here: |
49 |
https://github.com/gentoo-perl/perl-experimental/blob/master/eclass/perl-mb-tiny.eclass |
50 |
|
51 |
Its not perfect yet, and the documentation is wrong. It bases itself on the |
52 |
present perl-module.eclass and overrides everything applicable to focus on |
53 |
the task of building Module::Build::Tiny based distributions. |
54 |
|
55 |
This is an early query to the ML to get feedback on the general approach |
56 |
I've taken, and get an idea of whether I'm heading in the right direction |
57 |
or not. |
58 |
|
59 |
I would also be thinking about creating perl-mb.eclass and perl-eumm.eclass |
60 |
, for the 2 other dominant toolkits at this time, and then moving to |
61 |
transition packages that use perl-module.eclass to one of the 3. |
62 |
|
63 |
( This is really just a move to apply the method we presently use for |
64 |
non-perl packages to perl packages, for instance, we don't autodetect |
65 |
during src_configure whether a gentoo package uses cmake or autoconf, that |
66 |
would just be silly, we do the smart thing and have an eclass for cmake, |
67 |
and an eclass for autoconf ) |
68 |
|
69 |
If somebody else knows what they're doing here and can contribute a better |
70 |
version of perl-mb-tiny.eclass, that'd be cool too =) |
71 |
|
72 |
|
73 |
-- |
74 |
Kent |