Front page | perl.makemaker |
Postings from May 2002
Re: Module::Build design plans
Thread Previous
|
Thread Next
From:
Ken Williams
Date:
May 21, 2002 18:39
Subject:
Re: Module::Build design plans
Message ID:
B52159CE-6CC7-11D6-862D-003065F6D85A@mathforum.org
Hi Andreas,
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
a concern.
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
>>>>>> <schwern@pobox.com> said:
>
>> If may not be possible to get all the possible configuration problems
>> down
>> 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
>> or
>> 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...
>
> --
> andreas
>
-Ken
Thread Previous
|
Thread Next