Thread: [Module-build-general] Breaking CPAN installs using M::B
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Soren A <per...@wo...> - 2003-08-28 02:42:04
|
Hi, Ken! and All,
Hope you'all are doing good.
OK, Ken, I finally (YAPC::NA::2003 seems a bit of a ways back now,
doesn't it?) got subscribed to your mailing list, and I have an
immediate concern / complaint / observation to air.
Over the last several weeks (but not, unfortunately, within the last
several days), I've installed a lot of modules using CPAN. I've detected
that on my system, packages using Module::Build are broken wrt to
automatic installation via CPAN. They can be installed if, following the
CPAN blow-up, I issue the "look <package-name>" command and go in and do
things manually.
I believe the reason things are failing is that I have settings in my
CPAN/Config.pm that call `perl Makefile.PL verbose'. As the
administrator for this system I have good reasons for invoking the
Makefile.PL this way. I don't know if you are thinking that M::B as it
gets somehow called from that Makefile.PL is already handling this: but
from the immediate (unstudied) vantage point of my recent experience, it
sure looks like it isn't.
And that is a problem. IMHO, M::B and portability scripts which enable
it's use from the traditional MakeMaker-based invocation `perl
makefile.PL', *must* support or at least parse and accept without error,
*all* the things that have been possible to pass as arguments to that
familiar routine. I can't really recommend M::B yet to others after the
amount of extra trouble it's caused me (I had to get the DateTime
modules installed inahurry a few days ago) on account of this remaining
degree of non-compatibility.
Let me know what's up and how I can help.
I've got this setup:
-----------------------------------------------------------------------
Module::Build 0.19 in
/usr/local/share/perl/5.6.1/Module/Build.pm (for 5.6.1)
I haven't installed M::B to my 5.8.0 installation yet. I am on Debian
"Woody".
Best,
Soren Andersen
|
|
From: Michael G S. <sc...@po...> - 2003-08-28 03:41:31
|
On Wed, Aug 27, 2003 at 10:41:19PM -0400, Soren A wrote:
> And that is a problem. IMHO, M::B and portability scripts which enable
> it's use from the traditional MakeMaker-based invocation `perl
> makefile.PL', *must* support or at least parse and accept without error,
> *all* the things that have been possible to pass as arguments to that
> familiar routine.
As the vast majority of the arguments Makefile.PL accept make no sense for
Module::Build, or are prohibitively complicated to backport, this will
never happen.
As for silently accepting old Makefile.PL commands which it does not
implement, this sounds sketchy. At minimum a warning should be issued.
I think an error is ok since, in my world, its better to stop working
then ignore user input and bull forward. Consider, for example,
the consequences of ignoring 'DESTDIR' or 'PREFIX'. But that's up to Ken.
Module::Build should deal with the most common arguments one would put
into something automated like the CPAN shell. verbose must have
slipped by. Its a bit odd, it doesn't follow the convention of a lot
of others.
Here's a patch for it.
--- lib/Module/Build/Compat.pm 2003/08/28 03:35:44 1.1
+++ lib/Module/Build/Compat.pm 2003/08/28 03:38:21
@@ -95,7 +95,13 @@
sub makefile_to_build_args {
shift;
my @out;
+ my $verbose = 0;
foreach my $arg (@_) {
+ if( $arg eq 'verbose' ) { # special case for verbose
+ $verbose++;
+ next;
+ }
+
my ($key, $val) = $arg =~ /^(\w+)=(.+)/ or die "Malformed argument '$arg'";
if (exists $Config{lc($key)}) {
push @out, 'config=' . lc($key) . "=$val";
@@ -107,6 +113,9 @@
push @out, "\L$key\E=$val";
}
}
+
+ push @out, "verbose=$verbose" if $verbose;
+
return @out;
}
--
Michael G Schwern sc...@po... http://www.pobox.com/~schwern/
I know you get this a lot, but what's an unholy fairy like you doing in a
mosque like this?
|
|
From: Soren A <per...@wo...> - 2003-08-28 08:08:44
|
For future ref, it's ok, I don't need CC:s. Thanks all the same.
On Wed, Aug 27, 2003 at 08:40:14PM -0700, Michael G Schwern wrote:
{...}
> Module::Build should deal with the most common arguments one would put
> into something automated like the CPAN shell. verbose must have
> slipped by. Its a bit odd, it doesn't follow the convention of a lot
> of others.
Exactly. It's quite odd. It's the only argument that the ordinary
invocation takes, actually, AFAICR, that's just a single statement and
not a key-value pair.
> Here's a patch for it.
Looks good. Thanks, trying it now ... {much time elapsing} HUHHH, what a
stupid fellow I am. I tried it out on the most likely candidate I could
lay my hands on, M::B itself ...
Tried to just do a "get" to the CPAN build area in the CPAN shell, then
patch the file in-place. DON'T anybody else waste your time trying that.
After much fussing I decided that it must mess with `make' horribly,
upsetting by altering the file timestamps. With care I applied the patch
and let CPAN run 'test' and everything was fine.
At least I now have M::B in 5.8.0 as well as in 5.6.1, that's a plus.
Thanks for the patch, Michael. I dub thee Sir Insty-Patch.
Soren
|
|
From: Soren A <per...@wo...> - 2003-08-28 08:44:37
|
Aha. OK. Confession: how dumb I really do feel at this moment. I haven't
been thinking about M::B for too long. So, ...
When I wrote previously that "I tried Michael's patch with the first
CPAN module that uses Module::Build that I could lay hands on, M::B it's
self", that didn't make a lot od sense, did it? Actually, is it true as
I now realize that *using good 'ol CPAN.pm*, the *only* package out
there that's going to use Module::Build to build itself is
Module::Build, itself ("Who's on First" -- whaa? that's what I'm asking,
you dope, who's on first?")? because calling `make' is so hardwired in
to CPAN.pm? It's always going to try to build modules the same way.
I used CPAN to fetch-prepare-install Ken's Path::Class a minute ago and
the discomforting realization of my ignorance hit me. So are we just
waiting for the world to shift to CPANPLUS? Hmmm, now I have to (after
some sleep) hit the Fine Documentation.
Soren
|
|
From: Michael G S. <sc...@po...> - 2003-08-28 10:28:27
|
On Thu, Aug 28, 2003 at 04:43:54AM -0400, Soren A wrote:
> Aha. OK. Confession: how dumb I really do feel at this moment. I haven't
> been thinking about M::B for too long. So, ...
>
> When I wrote previously that "I tried Michael's patch with the first
> CPAN module that uses Module::Build that I could lay hands on, M::B it's
> self", that didn't make a lot od sense, did it? Actually, is it true as
> I now realize that *using good 'ol CPAN.pm*, the *only* package out
> there that's going to use Module::Build to build itself is
> Module::Build, itself ("Who's on First" -- whaa? that's what I'm asking,
> you dope, who's on first?")? because calling `make' is so hardwired in
> to CPAN.pm? It's always going to try to build modules the same way.
AFAIK nobody's seriously tried patching CPAN.pm for Module::Build. I doubt
it would be easy.
> I used CPAN to fetch-prepare-install Ken's Path::Class a minute ago and
> the discomforting realization of my ignorance hit me. So are we just
> waiting for the world to shift to CPANPLUS?
Pretty much.
Fortunately the Module::Build Makefile.PL compatibility wrapper is pretty
good so its pretty moot.
--
Michael G Schwern sc...@po... http://www.pobox.com/~schwern/
If it's stupid, but it works, it isn't stupid.
|
|
From: Dave R. <au...@ur...> - 2003-08-28 14:02:32
|
On Thu, 28 Aug 2003, Michael G Schwern wrote: > AFAIK nobody's seriously tried patching CPAN.pm for Module::Build. I doubt > it would be easy. ACtually, I sent a patch for this to Andreas quite some time ago. I could send it again. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Michael G S. <sc...@po...> - 2003-08-28 20:45:31
|
On Thu, Aug 28, 2003 at 09:01:53AM -0500, Dave Rolsky wrote: > > AFAIK nobody's seriously tried patching CPAN.pm for Module::Build. I doubt > > it would be easy. > > ACtually, I sent a patch for this to Andreas quite some time ago. I could > send it again. Yeah, give him a kick. -- Michael G Schwern sc...@po... http://www.pobox.com/~schwern/ Operation Bitter Jungle Cat |
|
From: Ken W. <ke...@ma...> - 2003-08-28 13:51:14
|
On Thursday, August 28, 2003, at 03:43 AM, Soren A wrote:
> Aha. OK. Confession: how dumb I really do feel at this moment. I
> haven't
> been thinking about M::B for too long. So, ...
>
> When I wrote previously that "I tried Michael's patch with the first
> CPAN module that uses Module::Build that I could lay hands on, M::B
> it's
> self", that didn't make a lot od sense, did it? Actually, is it true as
> I now realize that *using good 'ol CPAN.pm*, the *only* package out
> there that's going to use Module::Build to build itself is
> Module::Build, itself ("Who's on First" -- whaa? that's what I'm
> asking,
> you dope, who's on first?")? because calling `make' is so hardwired in
> to CPAN.pm? It's always going to try to build modules the same way.
Actually, any distribution that includes a "passthrough" or "small"
Makefile.PL (as described in Module::Build::Compat) will also be built
by CPAN using Module::Build. However, there aren't many of those at
the moment on CPAN as far as I know.
> I used CPAN to fetch-prepare-install Ken's Path::Class a minute ago and
> the discomforting realization of my ignorance hit me. So are we just
> waiting for the world to shift to CPANPLUS? Hmmm, now I have to (after
> some sleep) hit the Fine Documentation.
What happened with Path::Class? It's got a normal Makefile.PL that
uses MakeMaker, so it should have worked fine with the 'verbose' flag
even before Schwern's patch.
-Ken
|
|
From: Dave R. <au...@ur...> - 2003-08-28 14:04:06
|
On Thu, 28 Aug 2003, Ken Williams wrote: > Actually, any distribution that includes a "passthrough" or "small" > Makefile.PL (as described in Module::Build::Compat) will also be built > by CPAN using Module::Build. However, there aren't many of those at > the moment on CPAN as far as I know. I have a bunch that do that, including DateTime::TimeZone, DateTime::Locale, DateTime::Format::MySQL, DateTime::Format::ICal, Log::Dispatch, Alzabo, and Thesaurus. The last one may have been the first module to ever use the passthrough Makefile.PL stuff. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Soren A <per...@wo...> - 2003-08-28 20:46:48
|
On Thu, Aug 28, 2003 at 09:03:54AM -0500, Dave Rolsky wrote: > On Thu, 28 Aug 2003, Ken Williams wrote: >=20 > > Actually, any distribution that includes a "passthrough" or "small" > > Makefile.PL (as described in Module::Build::Compat) will also be built > > by CPAN using Module::Build. However, there aren't many of those at > > the moment on CPAN as far as I know. =20 > I have a bunch that do that, including DateTime::TimeZone, > DateTime::Locale, DateTime::Format::MySQL, DateTime::Format::ICal, > Log::Dispatch, Alzabo, and Thesaurus. The last one may have been the > first module to ever use the passthrough Makefile.PL stuff. Ah, see now that makes sense. I installed a bunch of the modules that comprise Bundle::DateTime last week, and it was some of those, including I am sure, DateTime::Locale, that were breaking when using CPAN, for me. So I wasn't hallucinating all this. Soren |
|
From: Soren A <per...@wo...> - 2003-08-28 20:30:39
|
On Thu, Aug 28, 2003 at 08:51:20AM -0500, Ken Williams wrote:
> Subject: Re: [PATCH] Re: [Module-build-general] Breaking CPAN installs..
[Sorry to go messing w/ the subject: line, just trimmed it a bit for
esthetics...]
> On Thursday, August 28, 2003, at 03:43 AM, Soren A wrote:
>=20
> >When I wrote previously that "I tried Michael's patch with the first
> >CPAN module that uses Module::Build that I could lay hands on, M::B
> >it's self", that didn't make a lot od sense, did it? Actually, is it
> >true as I now realize that *using good 'ol CPAN.pm*, the *only*
> >package out there that's going to use Module::Build to build itself
> >is Module::Build, itself ("Who's on First" -- whaa? that's what I'm
> >asking, you dope, who's on first?")? because calling `make' is so
> >hardwired in to CPAN.pm? It's always going to try to build modules
> >the same way.
> Actually, any distribution that includes a "passthrough" or "small"=20
> Makefile.PL (as described in Module::Build::Compat) will also be built=20
> by CPAN using Module::Build. However, there aren't many of those at=20
> the moment on CPAN as far as I know.
And I ASSumed that one of your newer modules, like Path::Class, would be
one. My mistake, Ken, sorry for the confusion.
> >I used CPAN to fetch-prepare-install Ken's Path::Class a minute ago and
> >the discomforting realization of my ignorance hit me. So are we just
> >waiting for the world to shift to CPANPLUS? Hmmm, now I have to (after
> >some sleep) hit the Fine Documentation.
=20
> What happened with Path::Class? It's got a normal Makefile.PL that=20
> uses MakeMaker, so it should have worked fine with the 'verbose' flag=20
> even before Schwern's patch.
Nothing bad happened (now you understand, it was my expectations that
were in error). Is there anywhere being kept a list, of what CPAN
modules are using Module::Build and might have such a "pass-through"
Makefile.PL? Is there any way to query for this?
Anyway, Class::Path just built the way any old CPAN module would. What I
wanted was to see the passthrough Makefile.PL in action (and now that
I've had some sleep I am understanding about the "passthrough"
Makefile.PL being an optional technique to be found in some, but by no
means all, modules that are released with Build.PL's).
Thanks for the clarifications.
Soren
|
|
From: Ken W. <ke...@ma...> - 2003-08-28 14:05:23
|
On Wednesday, August 27, 2003, at 10:40 PM, Michael G Schwern wrote:
>
> Module::Build should deal with the most common arguments one would put
> into something automated like the CPAN shell. verbose must have
> slipped by. Its a bit odd, it doesn't follow the convention of a lot
> of others.
>
> Here's a patch for it.
>
Here's how I'll apply - actually, I've got two variants, which one
should I use? I.e., how unique is 'verbose'?
-Ken
Index: lib/Module/Build/Compat.pm
===================================================================
RCS file:
/cvsroot/module-build/Module-Build/lib/Module/Build/Compat.pm,v
retrieving revision 1.29
diff -u -r1.29 Compat.pm
--- lib/Module/Build/Compat.pm 13 Aug 2003 15:27:27 -0000 1.29
+++ lib/Module/Build/Compat.pm 28 Aug 2003 14:01:46 -0000
@@ -96,7 +96,9 @@
shift;
my @out;
foreach my $arg (@_) {
- my ($key, $val) = $arg =~ /^(\w+)=(.+)/ or die "Malformed argument
'$arg'";
+ my ($key, $val) = ($arg =~ /^(\w+)=(.+)/ ? ($1, $2) :
+ $arg =~ /^(\w+)$/ ? ($1, 1) :
+ die "Malformed argument '$arg'");
if (exists $Config{lc($key)}) {
push @out, 'config=' . lc($key) . "=$val";
} elsif (exists $makefile_to_build{$key}) {
Index: lib/Module/Build/Compat.pm
===================================================================
RCS file:
/cvsroot/module-build/Module-Build/lib/Module/Build/Compat.pm,v
retrieving revision 1.29
diff -u -r1.29 Compat.pm
--- lib/Module/Build/Compat.pm 13 Aug 2003 15:27:27 -0000 1.29
+++ lib/Module/Build/Compat.pm 28 Aug 2003 14:02:13 -0000
@@ -96,7 +96,9 @@
shift;
my @out;
foreach my $arg (@_) {
- my ($key, $val) = $arg =~ /^(\w+)=(.+)/ or die "Malformed argument
'$arg'";
+ my ($key, $val) = ($arg =~ /^(\w+)=(.+)/ ? ($1, $2) :
+ $arg =~ /^(verbose)$/ ? ($1, 1) :
+ die "Malformed argument '$arg'");
if (exists $Config{lc($key)}) {
push @out, 'config=' . lc($key) . "=$val";
} elsif (exists $makefile_to_build{$key}) {
|
|
From: Michael G S. <sc...@po...> - 2003-08-28 20:19:48
|
On Thu, Aug 28, 2003 at 09:05:11AM -0500, Ken Williams wrote:
> Here's how I'll apply - actually, I've got two variants, which one
> should I use? I.e., how unique is 'verbose'?
Both your patches won't don't translate "perl Makefile.PL verbose verbose"
to verbose=2 which is how it should work. Though at this time it doesn't
look like you have verbosity levels in Module::Build.
Looking at the MM argument parsing code, I think the only other special
argument is 'help'. However...
$ perl Makefile.PL help
Undefined subroutine &ExtUtils::MakeMaker::help called at lib/ExtUtils/MakeMaker.pm line 664.
So I wouldn't worry about that. :)
> Index: lib/Module/Build/Compat.pm
> ===================================================================
> RCS file:
> /cvsroot/module-build/Module-Build/lib/Module/Build/Compat.pm,v
> retrieving revision 1.29
> diff -u -r1.29 Compat.pm
> --- lib/Module/Build/Compat.pm 13 Aug 2003 15:27:27 -0000 1.29
> +++ lib/Module/Build/Compat.pm 28 Aug 2003 14:01:46 -0000
> @@ -96,7 +96,9 @@
> shift;
> my @out;
> foreach my $arg (@_) {
> - my ($key, $val) = $arg =~ /^(\w+)=(.+)/ or die "Malformed argument
> '$arg'";
> + my ($key, $val) = ($arg =~ /^(\w+)=(.+)/ ? ($1, $2) :
> + $arg =~ /^(\w+)$/ ? ($1, 1) :
> + die "Malformed argument '$arg'");
> if (exists $Config{lc($key)}) {
> push @out, 'config=' . lc($key) . "=$val";
> } elsif (exists $makefile_to_build{$key}) {
>
>
> Index: lib/Module/Build/Compat.pm
> ===================================================================
> RCS file:
> /cvsroot/module-build/Module-Build/lib/Module/Build/Compat.pm,v
> retrieving revision 1.29
> diff -u -r1.29 Compat.pm
> --- lib/Module/Build/Compat.pm 13 Aug 2003 15:27:27 -0000 1.29
> +++ lib/Module/Build/Compat.pm 28 Aug 2003 14:02:13 -0000
> @@ -96,7 +96,9 @@
> shift;
> my @out;
> foreach my $arg (@_) {
> - my ($key, $val) = $arg =~ /^(\w+)=(.+)/ or die "Malformed argument
> '$arg'";
> + my ($key, $val) = ($arg =~ /^(\w+)=(.+)/ ? ($1, $2) :
> + $arg =~ /^(verbose)$/ ? ($1, 1) :
> + die "Malformed argument '$arg'");
> if (exists $Config{lc($key)}) {
> push @out, 'config=' . lc($key) . "=$val";
> } elsif (exists $makefile_to_build{$key}) {
>
--
Michael G Schwern sc...@po... http://www.pobox.com/~schwern/
"Let's face it," said bearded Rusty Simmons, opening a can after the
race. "This is a good excuse to drink some beer." At 10:30 in the
morning? "Well, it's past noon in Dublin," said teammate Mike
[Joseph] Schwern. "It's our duty."
-- "Sure, and It's a Great Day for Irish Runners"
Newsday, Sunday, March 20, 1988
|
Thanks for helping keep SourceForge clean.
X