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

Module::Build design plans

Thread Next
Ken Williams
April 27, 2002 22:43
Module::Build design plans
Message ID:
[I just sent this message to the 'Fink' list, I thought it might 
be of some interest to the people here, too.]


I'm the author of the relatively experimental Module::Build 
module.  It, or something like it, will eventually become the 
replacement for ExtUtils::MakeMaker (EU::MM).  EU:MM needs to be 
replaced for several reasons, some of which I mention in the 
Module::Build documentation on CPAN.  Michael Schwern, current 
maintainer of EU::MM, agrees.

I want to ask the Fink community what kinds of considerations I 
should be putting into the design.  So far I've been focusing on 
its flexibility and extendibility in customizing build 
processes, which I think is already a big improvement over 
EU::MM.  I haven't given much thought to packaging, though, so 
I'd appreciate any feedback you can give me.

Currently in EU::MM, dependencies are handled by a "PREREQ" 
field in a function call.  This means that it's impossible to 
programmatically determine dependency hierarchies in advance, 
which makes automatic installation very tricky (tools like basically just try to forge ahead, and allow you to 
auto-install dependencies that fail at runtime).  It also 
doesn't allow for "build dependencies", or optional 
dependencies, etc.

I'm thinking of creating meta-data files for Perl modules, 
similar to Fink's .info files.  The first step in the build 
process (similar to "perl Makefile.PL") would read this file and 
configure itself appropriately.  This file would NOT contain 
Perl code to be evaluated, since this opens up the possibilities 
of dynamically-determined dependencies.  It would just be a 
"flat" configuration file.  I haven't decided on a format for 
the file yet, but options might be Fink's format, YAML [1], XML 
(shudder), or something else.

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.

One of the larger goals with this is to get the "standard" 
mechanism for building & installing Perl modules closer to a 
"real" package management system.  Currently if you just use 
"perl Makefile.PL && make test && make install", you don't keep 
a record of dependencies, and it's very difficult to properly 
uninstall things later.

Thanks in advance for any advice.



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