Ok. That's my first attempt at the subject: "Split metafile generation into user overridable methods." The patch against ExtUtils-MakeMaker-6.30_03 is attached.
Some explanations are in order:
(1) The patch proposes to change the nature of EXTRA_META from a
string into a hash ref
- it also may be an array (ref) of pairs, if preserving the order
of appearance
is desirable.
Well, that's not compatible with 6.30_01, _02, and _03 with the
"paste this onto the end of the META.yml" thing. But it was experimental
and Schwern said that, as it was, it would not pass onto 6.31.
(2) There is now a method C<metafile_data> in ExtUtils::MM_Any
which spits the data to be dumped to META.yml
If EXTRA_META was set, the additional pairs are appended to
the data. If EXTRA_META contains keys such as 'license' and 'name'
which are already MakeMaker-generated you get a warning and
the given values are ignored.
The order of the fields in META.yml with respect to the previous EUMM
versions are preserved.
The additional keys 'installdirs' and 'version_from' that
C<metafile_target> documented (for example, in 6.30) and which were missing
in 6.30_01, _02, and _03 were restored. I don't know if the
removal was intentional or not.
I thought it would be a good idea to update the META.yml specification
link to:
'meta-spec' => {
url =>
'http://module-build.sourceforge.net/META-spec-v1.1.html',
version => 1.1*
},
But I am not sure since 'no_index' is at v1.2. Another doubt is
that 6.30_01 dumped the URL as
url: <http://module-build.sourceforge.net/META-spec-new.html>;
Should it be that way?
(3) There is now a method C<metafile_file> in ExtUtils::MM_Any
which transforms the metadata (as returned by C<metafile_data>)
into (fake) YAML.
Both metafile_data and metafile_file were abstracted from
the previous code of C<metafile_target> and separated according
to the description of RT ticket #21282.
The dumper was coded to mimick exactly the previous
behavior and extended to support nested hashes and strings
of arrays. It was done to cover the basic cases of
adding 'recommends' and 'require_build' hashes and
'no_index' fields (which contains arrays of strings).
That simulation made the code a bit more complex than
it could be. Among the features kept, there are:
* the original order of the pairs in the root hash
is preserved - so that what left metafile_data
pass orderly to YAML.
* keys and values in the root hash and 'requires'
are aligned:
name: Foo
version: 1
requires:
Test::More: 0
File::Spec: 0
* 'requires' pairs are sorted in a case-insensitive
fashion (as it was in previous versions)
New feature:
* nested hashes sort with { $a cmp $b }
(4) By now, I wrote a test script 't/metafile_file.t'
which tests the dumper via C<ExtUtils::MM_Any::metafile_file>.
Best regards,
Adriano Ferreira.
On 9/2/06, Michael_G_Schwern via RT <[EMAIL PROTECTED]> wrote:
<URL: http://rt.cpan.org/Ticket/Display.html?id=21282 > Reposting this for Adriano and makemaker@perl.org's benefit. On Sat Sep 02 14:45:01 2006, MSCHWERN wrote: > Adriano Ferreira wrote: > > The following patch extends EXTRA_META to accept hash refs as well it > > already accepts YAML-formatted text. > > > > This way I could write a Makefile.PL like > > > > use 5.006; > > use ExtUtils::MakeMaker; > > > > WriteMakefile( > > NAME => 'Foo', > > VERSION => '42', > > EXTRA_META => { > > recommends => { > > 'Test::Pod' => '1.18', > > 'Test::Pod::Coverage' => '1.04', > > } > > } > > > > ); > > This is a much better idea than my "paste this onto the end of the > META.yml" which makes my feet itch and I'm going to undocument right now > so it doesn't hold up 6.31. > > Probably even better is to simply expose the META.yml hash generation > method and allow the user to override. metafile_data() would simply > return the data which MakeMaker then turns into a META.yml file. > metafile_file() would take that and turn it into a file. > metafile_target would simply do the necessary make juju to paste the > metafile_file into the Makefile target. > > This has the nice side-effect of MakeMaker not having to depend on > META.yml. It can continue to use its crappy fake YAML generator and if > you write a metafile_data() that does something more complicated you can > override metafile_file() to use YAML.pm. > > I'm not holding up 6.31 for this, but its a very good idea. Patches > welcome.
eumm.diff
Description: Binary data
