develooper Front page | perl.makemaker | Postings from May 2002

Re: Module::Build design plans

Thread Previous | Thread Next
Ken Williams
May 21, 2002 18:39
Re: Module::Build design plans
Message ID:
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 
>>>>>> <> 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


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About