Thread: [Module::Build] Asking the unaskable
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Johan V. <jvr...@sq...> - 2006-03-17 14:35:06
|
For a while now I've been trying to follow de developments in the Module::* area. There's a question that's bugging me. It's probably 'not done' to ask it. Nevertheless, I do. I'm writing this new and flashy application (some scripts, modules, and data -- pure perl). Should I use ExtUtils::MakeMaker, Module::Build or Module::Install? -- Johan |
|
From: David G. <da...@hy...> - 2006-03-17 14:56:34
|
Johan Vromans wrote: > For a while now I've been trying to follow de developments in the > Module::* area. There's a question that's bugging me. It's probably > 'not done' to ask it. Nevertheless, I do. > > I'm writing this new and flashy application (some scripts, modules, > and data -- pure perl). Should I use ExtUtils::MakeMaker, > Module::Build or Module::Install? At this point, with CPAN.pm support for Module::Build improved, and Module::Build going into the core in blead, I think Module::Build has the edge over ExtUtils::MakeMaker. Module::Install is a tougher question. Honestly, I think it may come down to your philosophy about installers. Module::Install bundles itself in the distribution -- you don't need to worry about what version of the install toolchain is present on users' machines. On the other hand, you need to re-release your module each time critical bugs are found in Module::Install. You might want to see this journal entry for Adam Kennedy for some additional thoughts: http://use.perl.org/~Alias/journal/28855 Personally, I think that Module::Install is solving a problem that will be going away with the latest releases of CPAN.pm and Module::Build -- but you then have to rely upon users to upgrade CPAN.pm and Module::Build accordingly. On the other hand, I like that it can bundle my "build_requires" modules -- but there's no reason you can't do that by hand already if you really need to. Regards, David |
|
From: John P. <jpe...@ro...> - 2006-03-17 15:06:04
|
David Golden wrote: > Module::Install bundles itself in the distribution -- you don't need > to worry about what version of the install toolchain is present on > users' machines. Unfortunately, that's not currently true in practice. See the second entry on this ticket: http://rt.cpan.org/Public/Bug/Display.html?id=14732 I haven't had the time to make a formal bug report to M::I, but it appears that recent changes in the M::I API may break existing installs with no recourse for the normal user. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 |
|
From: John P. <jpe...@ro...> - 2006-03-17 15:01:33
|
Johan Vromans wrote: > I'm writing this new and flashy application (some scripts, modules, > and data -- pure perl). Should I use ExtUtils::MakeMaker, > Module::Build or Module::Install? <vorlon>Module installation is a three-edged sword</vorlon> ExtUtils::MakeMaker is installed by core Perl going back to the depths of history, but the API is very convoluted, so anything out of the ordinary is difficult. If you don't have any unusual needs, this is most likely to Just Work(TM) everywhere. Module::Install is intended to be a better interface to creating a Makefile, but it is still fairly new and (IMHO) a little rough around the edges (especially the POD). It has the big advantage of not requiring the _user_ to install anything else (since the M::I files are included in the distro). Module::Build is more mature than M::I, but more designed for reuse than EU::MM. It does require that the user install M::B before they can install your module, but recent Bundle::CPANPLUS and Bundle::CPAN both install M::B first. M::B has been added to bleadperl (with some degree of success) and is intended to be core in v5.10.0. I'm using Module::Build going forward for all of my modules, because I find I can do more intelligent installers. YMMV. HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 |
|
From: Ken W. <ke...@ma...> - 2006-03-17 23:12:31
|
On Mar 17, 2006, at 8:34 AM, Johan Vromans wrote: > I'm writing this new and flashy application (some scripts, modules, > and data -- pure perl). Should I use ExtUtils::MakeMaker, > Module::Build or Module::Install? You realize you've walked into a lion's den and asked whether meat or eggplant tastes better, right? =) One concrete area where M::B has an advantage is its ability to add custom installable components to the mix. That's tough to do in a flexible way with MakeMaker. See the "ADVANCED RECIPES" in http://search.cpan.org/~kwilliams/ Module-Build-0.27_09/lib/Module/Build/Cookbook.pm . I'm unfortunately not very well-versed in Module::Install, so I probably can't comment too much about it. -Ken |
|
From: Johan V. <jvr...@sq...> - 2006-03-19 14:23:25
|
Ken Williams <ke...@ma...> writes: > You realize you've walked into a lion's den and asked whether meat > or eggplant tastes better, right? =) :-) > One concrete area where M::B has an advantage is its ability to add > custom installable components to the mix. That's tough to do in a > flexible way with MakeMaker. My main concern is whether it is sufficiently complete for 'real use'. But I must say that my Makefile.PL's are ususally quite straightforward and M::B had improved much since the last time I looked. > I'm unfortunately not very well-versed in Module::Install, so I > probably can't comment too much about it. As for many modules, there's very little (mostly: nothing) that needs to be built. It's just a matter of dropping the modules in the right place. For purposes like this, a simple installer (as opposed to a builder) would suffice. AFAIK, M::I tries to be just that: an installer. And, as already noticed, it includes its code in the kit so it doesn't need any modules pre-installed. Do you have plans to support something in the style of File::ShareDir? -- Johan |
|
From: David G. <da...@hy...> - 2006-03-19 18:30:06
|
Johan Vromans wrote: >> I'm unfortunately not very well-versed in Module::Install, so I >> probably can't comment too much about it. > > As for many modules, there's very little (mostly: nothing) that needs > to be built. It's just a matter of dropping the modules in the right > place. For purposes like this, a simple installer (as opposed to a > builder) would suffice. AFAIK, M::I tries to be just that: an > installer. And, as already noticed, it includes its code in the kit so > it doesn't need any modules pre-installed. Here's an example of the problems with Module::Install in its current state: I recently tried manually upgrading HTTP::Server::Simple to 0.18 after upgrading to Win32 ActiveState 5.8.8 (which supposedly supports cpan out of the box). However, H::S::S has M::I version 0.52, which uses an @INC hack which is incompatible with the way Config.pm is modified by AS5.8.8. The latest M::I is version 0.61, which fixes that bug. My interim fix, based on advice from Jesse, was to install M::I 0.61, delete the inc/ directory, and then run Makefile.PL, which recreates inc using 0.61 and then installs fine. The "proper" fix is to wait until Jesse releases H::S::S 0.19, which bundles M::I 0.61 (or better). So, at least in its current alpha/beta state, using M::I means that you've hooked yourself on to that dependency chain. I currently maintain about 17 CPAN distributions. If I used M::I for all of them, then whenever a bug is found in M::I, or whenever something else changes that breaks something in M::I, I would need to bump versions, repackage and re-release all 17 distributions to ensure that everyone will be successful installing my module. Yes, that can be automated, but it's still a big philosophy difference. And I cringe thinking about the scenario where hundreds of distributions all version bump and resubmit to PAUSE every time that M::I changes versions to fix a bug for some platform. Regards, David |
|
From: Tyler M. <ty...@yi...> - 2006-03-17 23:18:01
|
> >I'm writing this new and flashy application (some scripts, modules, > >and data -- pure perl). Should I use ExtUtils::MakeMaker, > >Module::Build or Module::Install? I havent tried it yet, but i've been keeping my eyes on App::Build: http://search.cpan.org/~spadkins/App-Build-0.62/lib/App/Build.pm It's a subclass of Module::Build that adds extra bells and whistles to support application (versus module) building. Cheers, Tyler |
|
From: Johan V. <jvr...@sq...> - 2006-03-19 13:19:31
|
Tyler MacDonald <ty...@yi...> writes: > I havent tried it yet, but i've been keeping my eyes on App::Build: > > http://search.cpan.org/~spadkins/App-Build-0.62/lib/App/Build.pm > > It's a subclass of Module::Build that adds extra bells and whistles > to support application (versus module) building. Yes, it looks promising, though it seems to have some problems as well. -- Johan |
Thanks for helping keep SourceForge clean.
X