Thread: [Module-build-general] Module::Build woes
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: James.FitzGibbon <Jam...@ta...> - 2003-06-24 20:38:46
|
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=3D$dir SITEPREFIX=3D$dir"
4. make module
5. test module
6. install module
7. zip up contents of $dir.
The result of which was an archive that was suitable for extraction =
relative to
$Config{installprefix}:
[app3d03:jfitzgi] ~/modules/5.8.0 (6) > unzip -t =
thread-barrier-0.100.aix4.zip
Archive: thread-barrier-0.100.aix4.zip
testing: man/ OK
testing: man/man3/ OK
testing: man/man3/Thread::Barrier.3 OK
testing: lib/ OK
testing: lib/perl5/ OK
testing: lib/perl5/5.8.0/ OK
testing: lib/perl5/5.8.0/aix-thread-multi/ OK
testing: lib/perl5/site_perl/ OK
testing: lib/perl5/site_perl/5.8.0/ OK
testing: lib/perl5/site_perl/5.8.0/Thread/ OK
testing: lib/perl5/site_perl/5.8.0/Thread/Barrier.pm OK
testing: lib/perl5/site_perl/5.8.0/aix-thread-multi/ OK
testing: lib/perl5/site_perl/5.8.0/aix-thread-multi/auto/ OK
testing: lib/perl5/site_perl/5.8.0/aix-thread-multi/auto/Thread/ =
OK
testing: =
lib/perl5/site_perl/5.8.0/aix-thread-multi/auto/Thread/Barrier/ OK
testing: =
lib/perl5/site_perl/5.8.0/aix-thread-multi/auto/Thread/Barrier/.packlist =
OK
No errors detected in compressed data of thread-barrier-0.100.aix4.zip.
[app3d03:jfitzgi] ~/modules/5.8.0 (7) >
Recently, Dave Rolsky updated Log::Dispatch to use M::B. When I try to =
use the bundler
on that, it completely ignores the M::B::Compat translated =
"prefix=3D$dir siteprefix=3D$dir" directives:
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (552) > perl Makefile.PL =
PREFIX=3D/tmp/foo SITEPREFIX=3D/tmp/foo
perl Build.PL prefix=3D/tmp/foo siteprefix=3D/tmp/foo
Creating custom builder _build/lib/MyModuleBuilder.pm in _build/lib
Checking whether your kit is complete...
Looks good
Creating new 'Build' script for 'Log-Dispatch' version '2.06'
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (553) > make
./Build
lib/Log/Dispatch.pm -> blib/lib/Log/Dispatch.pm
lib/Log/Dispatch/Syslog.pm -> blib/lib/Log/Dispatch/Syslog.pm
lib/Log/Dispatch/Handle.pm -> blib/lib/Log/Dispatch/Handle.pm
lib/Log/Dispatch/Output.pm -> blib/lib/Log/Dispatch/Output.pm
lib/Log/Dispatch/Email.pm -> blib/lib/Log/Dispatch/Email.pm
lib/Log/Dispatch/Base.pm -> blib/lib/Log/Dispatch/Base.pm
lib/Log/Dispatch/Screen.pm -> blib/lib/Log/Dispatch/Screen.pm
lib/Log/Dispatch/File.pm -> blib/lib/Log/Dispatch/File.pm
lib/Log/Dispatch/ApacheLog.pm -> blib/lib/Log/Dispatch/ApacheLog.pm
lib/Log/Dispatch/Email/MailSend.pm -> =
blib/lib/Log/Dispatch/Email/MailSend.pm
lib/Log/Dispatch/Email/MIMELite.pm -> =
blib/lib/Log/Dispatch/Email/MIMELite.pm
lib/Log/Dispatch/Email/MailSender.pm -> =
blib/lib/Log/Dispatch/Email/MailSender.pm
lib/Log/Dispatch/Email/MailSendmail.pm -> =
blib/lib/Log/Dispatch/Email/MailSendmail.pm
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (554) > make install
./Build install
Warning: You do not have permissions to install into =
/opt/3d/lib/perl5/site_perl/5.8.0 at =
/opt/3d/lib/perl5/5.8.0/ExtUtils/Install.pm line 84.
mkdir /opt/3d/lib/perl5/site_perl/5.8.0/Log: The file access permissions =
do not allow the specified action. at =
/opt/3d/lib/perl5/5.8.0/ExtUtils/Install.pm line 137
gmake: *** [install] Error 255
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (555) >
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=3D/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.p=
m
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}.
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=3D/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) >
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.
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.
Any thoughts?
Thanks.
--
j.
James FitzGibbon =20
Consultant, Ajilon Services, TTS-3D@CC-950=20
jam...@ta...
voice/fax 612-304-6121/3277
|
|
From: Ken W. <ke...@ma...> - 2003-06-25 19:58:42
|
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
|
|
From: Dave R. <au...@ur...> - 2003-06-25 21:56:53
|
On Wed, 25 Jun 2003, Ken Williams wrote: > > 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. Also, I sent Andreas a patch a while back to make CPAN.pm support M::B directly. It was against 1.59_54, but I suspect it'd still apply. I think Ken also put it in the Module-Build CVS repository. It doesn't add support for M::B directives, though. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
Thanks for helping keep SourceForge clean.
X