Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10
Status: Beta
Brought to you by:
kwilliams
|
From: Brian I. <in...@tt...> - 2002-10-28 06:42:09
|
On 27/10/02 23:20 -0600, Dave Rolsky wrote: > On Sun, 27 Oct 2002, Brian Ingerson wrote: > > > FYI. (NOTE: Even though this seems like a competitive module, I > > really think that Module::Build and CPAN::MakeMaker are somewhat > > orthoganal. I'm looking forward to working together. There is a good > > chance that these modules could nicely complement each other. Let the > > thinking begin :) > > I like that self-instaling feature. I wonder if we could/should > incorporate that for Module::Build. > > Maybe we could offer a 'Build uberdist' feature or something that would > simply incorporate all of the M::B files into the tarball. As long as > they end up untarring into the top-level of the distro (./Module, > ./Module/Base.pm, etc) it'd just work. You have to make sure that an *installed* copy of M::B reloads the local copy. The installed version will always be found first. But ultimately, it's the local copy you want to execute, because that is the one that the module author configured his distribution for. This is *essential*. If you do it, you'll never have versioning problems. If you don't you'll be plagued by them. One problem the current M::B faces is that it not only needs to get a copy of M::B on every install (an extremely formidable task in its own right) it also needs to have a compatible version of itself everywhere. How do you advance? CPAN::MM skirts around this nicely. If you do the self install route, you have one other issue to tackle. What happens to all the existing M::B installs? They don't know how to play the game. They must be removed, or you must change your module name. I ran into this problem with Inline::MakeMaker, the precedent to C::MM. I was going to need to find a way to nuke the old ones. Now I'm saved by the fact that I can move all the planned Inline logic into C::MM which doesn't (and won't) have legacy problems. Most importantly, if you go this route, please don't put M::B in core Perl. It would be completely illogical, and offer no advantage. > This could even be the default for Module::Build. Think how freaking cool > this would be! M::B would _just work_, whenever an author chose to use > it. This would also mean they could always use a minimal passthrough > Makefile.PL and know it'd work with existing versions of CPAN.pm and > future versions (and CPANPLUS too). I can see a world where authors could choose either M::B or C::MM, or even both simultaneously! > Some of the other (todo) features would be nice too, like handling > bundling of other modules and support for making PPMs. And it be nicer still if there were a way to share this code. For instance an author could download a bundling plugin that supported both M::B and C::M and that code would get stuffed into their distribution automatically. See Ken? We shoulda spent more time talking and less time having fun at OSCon ;) Cheers, Brian |