Front page | perl.makemaker |
Postings from May 2002
Re: Module::Build design plans
From: Ken Williams
May 21, 2002 18:39
Re: Module::Build design plans
Message ID: B52159CE-6CC7-11D6-862D-003065F6D85A@mathforum.org
When I first read this message back in April, I was going to reply and
tell you why I thought your version was all wrong. But now a month
later, I found myself working on it, and came around completely to agree
with what you've said. =)
I'm hoping to use YAML as the format for the metadata file, because I
have no interest in inventing another serialization/markup format, and
the following formats are unsatisfactory in some way or another:
XML - too big a gun, too yucky
Data::Dumper - requires an eval() to parse
Storable - not human-readable
Previously I was thinking that module developers would hand-build the
metadata files, so I was a little worried about YAML's whitespace
strictness, but if the files are going to be created automatically by
the developers during the packaging process, the whitespace isn't really
If anyone really thinks I really really have to use XML, speak up.
On Tuesday, April 30, 2002, at 04:32 PM, Andreas J. Koenig wrote:
>>>>>> On Sun, 28 Apr 2002 13:12:49 -0400, Michael G Schwern
>>>>>> <firstname.lastname@example.org> said:
>> If may not be possible to get all the possible configuration problems
>> to just a static config file. You'll likely still need the ability for
>> modules to call perl code for various stages of the build &
>> installation. A
>> good exercise would be to take something really complicated, like PDL
>> WxPerl and think "how would I do this in Module::Build"?
> I believe MakeMaker should be more or less preserved and a parallel
> universe should be dedicated to *maintain metadata*. This parallel
> world should be built *around* MakeMaker. On the developer's machine
> you can always run MakeMaker without a security problem, because who
> wrote that Makefile.PL again? So let the developer's MakeMaker write
> metadata and distribute these within the distribution. The consumer
> can then read the metadata and find a hint if Makefile.PL must be
> executed or not. There are these clever packages like mod_perl that
> just shine because they can run perl. No configuration options will
> ever be enough to cover the really clever stuff. The parallel universe
> can shine when it proves it can install the proverbial 80% of CPAN
> with the metadata file.
> If done right, this will provide seemless integration of old and new
> world. It will also provide the extensibility of MM and it will
> provide metadata for 100% of CPAN, even for those cases that need
> MakeMaker to run on the costumer's site.
>>> What other things need to be in the info-files? Module
>>> (distribution) name should be there, but version should probably
>>> not be (they're specified in the module files themselves).
>>> Patches aren't relevant, of course.
> The metadata file should be redundant with the rest of the
> distribution. It should be distributable separately with maximum
> information. So, of course it should contain the version number.
> Of course, this is only my old rant and I never came around to work on
> it. Feel free to follow a different vision...