>>>>> 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... -- andreasThread Previous | Thread Next