Re: [Module-build-general] Module::Build woes

[Ken W. <ke...@ma...>]

On Tuesday, June 24, 2003, at 03:33  PM, James.FitzGibbon wrote:

>
> I love Module::Build.  I hate Module::Build.  I love the idea, but the  
> hassles involved
> in providing a transition from E::MM to it are driving me up the wall.
> Perhaps someone can help.
>
> I'm have a script that will fetch from CPAN and bundle a module into a  
> zipfile for
> later deployment on multiple machines.  With Makefile.PL based modules  
> it works fine, but
> M::B (or M::B::Compat) modules break it.
>
> My bundler script uses CPAN.pm, so I have no choice but to use  
> M::B::Compat to tackle this
> problem.  Up till now, the basic flow was:
>
> 1. Create a temp dir for installation
> 2. get the module
> 3. Set $CPAN::Config->{makepl_arg} to "PREFIX=$dir SITEPREFIX=$dir"
> 4. make module
> 5. test module
> 6. install module
> 7. zip up contents of $dir.

I think it would be much better to use 'distdir' (or 'DISTDIR' for  
MakeMaker) for this.  PREFIX and SITEPREFIX are too DWIMmy to really  
work reliably, and distdir is created specifically for what you're  
doing.  Recent versions of MakeMaker support DISTDIR too.


> There is the 'destdir' parameter, but that doesn't do the same thing  
> as overriding
> prefix:
>
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (592) > perl Build.PL  
> destdir=/tmp/foo
> Deleting _build
> Creating custom builder _build/lib/MyModuleBuilder.pm in _build/lib
> Checking whether your kit is complete...
> Looks good
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Log-Dispatch' version '2.06'
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (593) > ./Build
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (594) > ./Build fakeinstall
> Installing /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Syslog.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Handle.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Output.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Base.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Screen.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/File.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/ApacheLog.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/ 
> MailSend.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/ 
> MIMELite.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/ 
> MailSender.pm
> Installing  
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/ 
> MailSendmail.pm
>
> because it creates an installation hierarchy relative to / instead of  
> $Config{installprefix}.

I'd argue that it's better to make it relative to '/'.  On my machine  
(OS X), $Config{installprivlib} and $Config{installsitelib} and  
$Config{installman1dir} don't share any directory components except for  
'/' :

  installprivlib='/System/Library/Perl'
  installsitelib='/Library/Perl'
  installman1dir='/usr/share/man/man1'

What would you specify for PREFIX or SITEPREFIX in this case?  There  
would really be no way to get it to work the way you want.  Using  
destdir you can get it to work really easily.

So yeah, it's not the same, but it's better. =)


>
> What's worse, M::B::Compat doesn't let me pass M::B directives on the  
> command line
> (only E::MM ones), so I can' use the $CPAN::Config->{makepl_arg}  
> override:
>
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (637) > perl Makefile.PL  
> destdir=/tmp/foo
> Unknown parameter 'destdir' at  
> /home_dir/jfitzgi/myperl/lib/perl5/site_perl/5.8.0/Module/Build/ 
> Compat.pm line 26.
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (638) >

I'm not sure it makes much sense to allow M::B directives to  
Makefile.PL.  It's pretending to be a Makefile.PL and emulating its  
interface.

It might make sense to just lower-case all unknown parameters and send  
them through.  That's an easy patch if people agree that it's a good  
idea.

--- lib/Module/Build/Compat.pm  11 Jun 2003 14:40:57 -0000      1.25
+++ lib/Module/Build/Compat.pm  25 Jun 2003 19:55:35 -0000
@@ -98,7 +98,8 @@
        my $trans = $makefile_to_build{$key};
        push @out, ref($trans) ? $trans->($val) : "$trans=$val";
      } else {
-      warn "Unknown parameter '$key'";
+      warn "Unknown parameter '$key', passing as '", lc($key), "'\n";
+      push @out, "\L$key\E=$val";
      }
    }


> Nor does CPAN allow me to override the script to call, so I can't have  
> it sneakily
> call Build.PL instead.  I *must* call Makefile.PL, but I can't use  
> destdir and passing
> prefix doesn't work properly.

PREFIX won't ever be supported under M::B if I have anything to say  
about it.  It's been very headachy under MakeMaker.


>
> See what I mean?  The idea behind M::B is great, but it simply doesn't  
> work if you are
> stuck using CPAN.pm and trying to automate things.

Complete emulation of MakeMaker-style Makefile.PL files would be great.  
  We're not there yet, though.  First we have to support all the things  
MakeMaker can do, then we have to provide the translation layer.


  -Ken