---------- Forwarded message ---------- From: Adriano Ferreira <[EMAIL PROTECTED]> Date: Mar 2, 2007 10:23 PM Subject: Re: [rt.cpan.org #21282] Split metafile generation into user overridable methods. To: [EMAIL PROTECTED], Michael G Schwern <[EMAIL PROTECTED]>
A few hundred years ago (more exactly, September 2006) I proposed a
patch for a better handling of META.yml generation for MakeMaker. And
then 6.31 came and then 6.32 a few days ago, but the patch rewrite
never reappeared, until now.
I just prepared a revised patch which incorporates your feedback, and
applies against revision 3935 at svn.schwern.org
Just to refresh, the patch features are:
(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.
(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 new values override
the old ones (you better know what you're doing).
The order of the fields in META.yml with respect
to the previous EUMM versions are preserved.
(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
* hash pairs are sorted in a case-insensitive
fashion (as 'requires' was handled in previous versions)
(4) By now, I wrote a test script 't/metafile_file.t'
which tests the dumper via C<ExtUtils::MM_Any::metafile_file>.
I tried this patch successfully in a few Perl versions and
architectures (most Windows and Cygwin).
Kind regards,
Adriano Ferreira
On 9/11/06, Michael_G_Schwern via RT <[EMAIL PROTECTED]> wrote:
<URL: http://rt.cpan.org/Ticket/Display.html?id=21282 > On Tue Sep 05 12:36:36 2006, [EMAIL PROTECTED] wrote: > (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. I think they should override. If they user wants to blow over what MakeMaker generates, let them. > 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. The removal was intentional. 6.30_01 changed our META.yml to match META spec and dropped those fields. > 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? At the time that was the URL to the 1.1 spec-to-be. Updating to 1.2 is appreciated. > (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) Excellent work, thank you. > New feature: > > * nested hashes sort with { $a cmp $b } Sort them case insensitively, too. > (4) By now, I wrote a test script 't/metafile_file.t' > which tests the dumper via C<ExtUtils::MM_Any::metafile_file>. Thank you. As I mentioned, I'm going to hold this until after 6.31.
eumm.diff
Description: application/txt
