module-build-general Mailing List for Module::Build (Page 156)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general — General discussion about Module::Build project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
| 2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
| 2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
| 2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2003-09-24 17:05:17
|
On Wed, Sep 24, 2003 at 05:29:23PM +0100, Steve Purkis <sp...@qu...> wrote: > On Wednesday, September 24, 2003, at 07:06 am, Yitzchak Scott-Thoennes > wrote: > > >Couldn't install Module::Build...the manpage names contain colons. > >Patch below fixes it. Looking at MakeMaker, I see MM_UWIN and MM_OS2 > >($^O eq 'uwin' and 'os2', respectively) also use '.', but have no > >special code in Module::Build. MakeMaker uses '__' for DOS, > >Module::Build uses '.' (via Platform/Windows.pm). > > Might make sense to use '__' for cygwin then, to preserve MM > compatibility. I assume you mean DOS, not cygwin. cygwin should use '.'. > I didn't see a Module::Build subclass for the others > you've mentioned, so I left them out of the original patch[1]. > > Perhaps stubs for them should be created too? Only if someone is going to try them. I don't even know what uwin is. |
|
From: Steve P. <sp...@qu...> - 2003-09-24 16:30:01
|
On Wednesday, September 24, 2003, at 07:06 am, Yitzchak Scott-Thoennes wrote: > Couldn't install Module::Build...the manpage names contain colons. > Patch below fixes it. Looking at MakeMaker, I see MM_UWIN and MM_OS2 > ($^O eq 'uwin' and 'os2', respectively) also use '.', but have no > special code in Module::Build. MakeMaker uses '__' for DOS, > Module::Build uses '.' (via Platform/Windows.pm). Might make sense to use '__' for cygwin then, to preserve MM compatibility. I didn't see a Module::Build subclass for the others you've mentioned, so I left them out of the original patch[1]. Perhaps stubs for them should be created too? -Steve [1] see http://sourceforge.net/mailarchive/ forum.php?thread_id=2800835&forum_id=10905 |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2003-09-24 08:25:57
|
Couldn't install Module::Build...the manpage names contain colons.
Patch below fixes it. Looking at MakeMaker, I see MM_UWIN and MM_OS2
($^O eq 'uwin' and 'os2', respectively) also use '.', but have no
special code in Module::Build. MakeMaker uses '__' for DOS,
Module::Build uses '.' (via Platform/Windows.pm).
I left os_type as Unix for cygwin. Darwin does the same. You might
think about implementing an os_flavor ala MakeMaker instead (where one
platform can list multiple types) with an os_flavor_is(@foo) routine
checking if any of the @foo types apply.
Would have been nice if install.t had caught the problem instead of
the actual install failing midway, but the install.t only tries a
top-level module name.
t/xs.t is failing tests 4 and 8. I'm not sure how to translate the
other things MM_Cygwin does into Module::Build terms.
diff -ruN Module-Build-0.20.orig/MANIFEST Module-Build-0.20/MANIFEST
--- Module-Build-0.20.orig/MANIFEST 2003-08-05 09:45:51.000000000 -0700
+++ Module-Build-0.20/MANIFEST 2003-09-23 22:59:34.570513600 -0700
@@ -20,6 +20,7 @@
lib/Module/Build/Platform/VMS.pm
lib/Module/Build/Platform/VOS.pm
lib/Module/Build/Platform/Windows.pm
+lib/Module/Build/Platform/cygwin.pm
lib/Module/Build/Platform/darwin.pm
t/MANIFEST
t/Sample/Build.PL
diff -ruN Module-Build-0.20.orig/lib/Module/Build/Platform/cygwin.pm Module-Build-0.20/lib/Module/Build/Platform/cygwin.pm
--- Module-Build-0.20.orig/lib/Module/Build/Platform/cygwin.pm 1969-12-31 16:00:00.000000000 -0800
+++ Module-Build-0.20/lib/Module/Build/Platform/cygwin.pm 2003-09-23 22:23:13.474251200 -0700
@@ -0,0 +1,36 @@
+package Module::Build::Platform::cygwin;
+
+use strict;
+use Module::Build::Platform::Unix;
+
+use vars qw(@ISA);
+@ISA = qw(Module::Build::Platform::Unix);
+
+sub manpage_separator {
+ '.'
+}
+
+1;
+__END__
+
+
+=head1 NAME
+
+Module::Build::Platform::cygwin - Builder class for Cygwin platform
+
+=head1 DESCRIPTION
+
+This module provides some routines very specific to the cygwin
+platform.
+
+Please see the L<Module::Build> for the general docs.
+
+=head1 AUTHOR
+
+Initial stub by Yitzchak Scott-Thoennes, sth...@ef...
+
+=head1 SEE ALSO
+
+perl(1), Module::Build(3), ExtUtils::MakeMaker(3)
+
+=cut
End of Patch.
|
|
From: Dave R. <au...@ur...> - 2003-09-22 05:25:35
|
On Mon, 22 Sep 2003, Dave Rolsky wrote: > On Sun, 21 Sep 2003, Ken Williams wrote: > > > > Yes, but until that time it makes sense for module authors to use the > > > backwards compatibility layer and generate a Makefile.PL. > > > > Indeed. Dave, do you suppose you could revive the CGI.pm patch? > > I take it you mean CPAN.pm ;) > > Anyway, the old patch mostly applied. An updated patch for CPAN 1.76 > appears below my sig. A quick test with Acme::Lingua::Pirate::Perl > suggests it works. However, it still passes the EU::MM args to > Build.PL/Build, like UNINST=1. Gah, that was a bit mailer-mangled. Here it is again. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ --- lib/CPAN.pm 2003-07-31 09:53:06.000000000 -0500 +++ lib/CPAN.pm.new 2003-09-22 00:18:48.000000000 -0500 @@ -3966,17 +3966,40 @@ my($mpl) = File::Spec->catfile($packagedir,"Makefile.PL"); my($mpl_exists) = -f $mpl; - unless ($mpl_exists) { + my($bpl) = MM->catfile($packagedir,"Build.PL"); + my($bpl_exists) = -f $bpl; + unless ($mpl_exists or $bpl_exists) { # NFS has been reported to have racing problems after the # renaming of a directory in some environments. # This trick helps. sleep 1; - my $mpldh = DirHandle->new($packagedir) + my $dh = DirHandle->new($packagedir) or Carp::croak("Couldn't opendir $packagedir: $!"); - $mpl_exists = grep /^Makefile\.PL$/, $mpldh->read; - $mpldh->close; + foreach ($dh->read) { + $mpl_exists = /^Makefile\.PL$/; + $bpl_exists = /^Build\.PL$/; + } + $dh->close; } - unless ($mpl_exists) { + + # If this is a module that uses Module::Build then we need to + # install Module::Build. However, Module::Build uses _itself_ to + # install so to avoid a recursive prereq follow of doom, we + # explicitly do not try to install Module::Build when already + # install Module::Build. - Dave Rolsky + if ($bpl_exists and not grep { $_ eq "Module::Build" } $self->containsmods) { + my $nmo = $CPAN::META->instance("CPAN::Module","Module::Build"); + + unless ($nmo->inst_file and $nmo->uptodate) { + $CPAN::Frontend->myprint("The module you are installing requires the Module::Build package. +Either you do not have this module installed or you do not have the latest version. +It is recommended that you install the latest version now or +else it may not be possible to install this module"); + $self->follow_prereqs("Module::Build"); + } + } + + unless ($mpl_exists or $bpl_exists) { $self->debug(sprintf("makefilepl[%s]anycwd[%s]", $mpl, CPAN::anycwd(), @@ -3987,7 +4010,7 @@ $self->{'configure'} = $configure; } elsif (-f File::Spec->catfile($packagedir,"Makefile")) { $CPAN::Frontend->myprint(qq{ -Package comes with a Makefile and without a Makefile.PL. +Package comes with a Makefile and without a Makefile.PL or Build.PL. We\'ll try to build it with that Makefile then. }); $self->{writemakefile} = "YES"; @@ -4000,9 +4023,9 @@ } $cf =~ s|[/\\:]||g; # risk of filesystem damage $cf = "unknown" unless length($cf); - $CPAN::Frontend->myprint(qq{Package seems to come without Makefile.PL. - (The test -f "$mpl" returned false.) - Writing one on our own (setting NAME to $cf)\a\n}); + $CPAN::Frontend->myprint(qq{Package seems to come without Makefile.PL or Build.PL. + (The tests -f "$mpl" and -f "$bpl" returned false.) + Writing a Makefile.PL on our own (setting NAME to $cf)\a\n}); $self->{had_no_makefile_pl}++; sleep 3; @@ -4013,7 +4036,7 @@ or Carp::croak("Could not open >$mpl: $!"); $fh->print( qq{# This Makefile.PL has been autogenerated by the module CPAN.pm -# because there was no Makefile.PL supplied. +# because there was no Makefile.PL or Build.PL supplied. # Autogenerated on: }.scalar localtime().qq{ use ExtUtils::MakeMaker; @@ -4021,9 +4044,14 @@ }); $fh->close; + + $mpl_exists = 1; } } + $self->{makescript} = $mpl_exists ? "Makefile.PL" : $bpl_exists ? "Build.PL" : ""; + $self->{maketype} = $mpl_exists ? 'make' : $bpl_exists ? "Module::Build" : ""; + return $self; } @@ -4486,7 +4514,7 @@ # $switch = "-MExtUtils::MakeMaker ". # "-Mops=:default,:filesys_read,:filesys_open,require,chdir" # if $] > 5.00310; - $system = "$perl $switch Makefile.PL $CPAN::Config->{makepl_arg}"; + $system = "$perl $switch $self->{makescript} $CPAN::Config->{makepl_arg}"; } unless (exists $self->{writemakefile}) { local($SIG{ALRM}) = sub { die "inactivity_timeout reached\n" }; @@ -4523,16 +4551,17 @@ } else { $ret = system($system); if ($ret != 0) { - $self->{writemakefile} = "NO Makefile.PL returned status $ret"; + $self->{writemakefile} = "NO $self->{makescript} returned status $ret"; return; } } - if (-f "Makefile") { + if (($self->{maketype} eq "make" && -f "Makefile") || + ($self->{maketype} eq "Module::Build" && -f "Build")) { $self->{writemakefile} = "YES"; delete $self->{make_clean}; # if cleaned before, enable next } else { $self->{writemakefile} = - qq{NO Makefile.PL refused to write a Makefile.}; + qq{NO $self->{makescript} refused to write a Makefile/Build.PL.}; # It's probably worth it to record the reason, so let's retry # local $/; # my $fh = IO::File->new("$system |"); # STDERR? STDIN? @@ -4546,7 +4575,11 @@ if (my @prereq = $self->unsat_prereq){ return 1 if $self->follow_prereqs(@prereq); # signal success to the queuerunner } - $system = join " ", $CPAN::Config->{'make'}, $CPAN::Config->{make_arg}; + if ($self->{maketype} eq 'make') { + $system = join " ", $CPAN::Config->{'make'}, $CPAN::Config->{make_arg}; + } else { + $system = join " ", $self->perl, File::Spec->catfile( File::Spec->curdir, "Build" ), $CPAN::Config->{make_arg}; + } if (system($system) == 0) { $CPAN::Frontend->myprint(" $system -- OK\n"); $self->{'make'} = "YES"; @@ -4649,6 +4682,7 @@ # but we must have run it my $build_dir = $self->{build_dir} or die "Panic: no build_dir?"; my $makefile = File::Spec->catfile($build_dir,"Makefile"); + my $buildprereq = File::Spec->catfile($build_dir,"_build","prereq"); my(%p) = (); my $fh; if (-f $makefile @@ -4677,6 +4711,16 @@ } last; } + } elsif (-f $buildprereq + and + $fh = FileHandle->new("<$buildprereq")) { + while (<$fh>) { + my ($mod,$ver) = split /\s*=\s*/; + if ( defined $p{$mod} ) { + warn "Warning: PREREQ_PM mentions $mod more than once, last mention wins"; + } + $p{$mod} = $ver; + } } $self->{prereq_pm_detected}++; return $self->{prereq_pm} = \%p; @@ -4725,7 +4769,12 @@ local $ENV{PERL5LIB} = $ENV{PERL5LIB} || ""; $CPAN::META->set_perl5lib; - my $system = join " ", $CPAN::Config->{'make'}, "test"; + my $system; + if ($self->{maketype} eq "make") { + $system = join " ", $CPAN::Config->{'make'}, "test"; + } elsif ($self->{maketype} eq "Module::Build") { + $system = join " ", $self->perl, File::Spec->catfile( File::Spec->curdir, "Build" ), "test"; + } if (system($system) == 0) { $CPAN::Frontend->myprint(" $system -- OK\n"); $CPAN::META->is_tested($self->{'build_dir'}); @@ -4757,7 +4806,12 @@ return; } - my $system = join " ", $CPAN::Config->{'make'}, "clean"; + my $system; + if ($self->{maketype} eq "make") { + $system = join " ", $CPAN::Config->{'make'}, "clean"; + } elsif ($self->{maketype} eq "Module::Build") { + $system = join " ", $self->perl, File::Spec->catfile( File::Spec->curdir, "Build" ), "clean"; + } if (system($system) == 0) { $CPAN::Frontend->myprint(" $system -- OK\n"); @@ -4832,8 +4886,14 @@ return; } - my $system = join(" ", $CPAN::Config->{'make'}, - "install", $CPAN::Config->{make_install_arg}); + my $system; + if ($self->{maketype} eq "make") { + $system = join(" ", $CPAN::Config->{'make'}, + "install", $CPAN::Config->{make_install_arg}); + } elsif ($self->{maketype} eq "Module::Build") { + $system = join(" ", $self->perl, File::Spec->catfile( File::Spec->curdir, "Build" ), + "install", $CPAN::Config->{make_install_arg}); + } my($stderr) = $^O =~ /Win/i ? "" : " 2>&1 "; my($pipe) = FileHandle->new("$system $stderr |"); my($makeout) = ""; |
|
From: Dave R. <au...@ur...> - 2003-09-22 05:19:37
|
On Sun, 21 Sep 2003, Ken Williams wrote: > > Yes, but until that time it makes sense for module authors to use the > > backwards compatibility layer and generate a Makefile.PL. > > Indeed. Dave, do you suppose you could revive the CGI.pm patch? I take it you mean CPAN.pm ;) Anyway, the old patch mostly applied. An updated patch for CPAN 1.76 appears below my sig. A quick test with Acme::Lingua::Pirate::Perl suggests it works. However, it still passes the EU::MM args to Build.PL/Build, like UNINST=1. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ --- lib/CPAN.pm 2003-07-31 09:53:06.000000000 -0500 +++ lib/CPAN.pm.new 2003-09-22 00:18:48.000000000 -0500 @@ -3966,17 +3966,40 @@ my($mpl) = File::Spec->catfile($packagedir,"Makefile.PL"); my($mpl_exists) = -f $mpl; - unless ($mpl_exists) { + my($bpl) = MM->catfile($packagedir,"Build.PL"); + my($bpl_exists) = -f $bpl; + unless ($mpl_exists or $bpl_exists) { # NFS has been reported to have racing problems after the # renaming of a directory in some environments. # This trick helps. sleep 1; - my $mpldh = DirHandle->new($packagedir) + my $dh = DirHandle->new($packagedir) or Carp::croak("Couldn't opendir $packagedir: $!"); - $mpl_exists = grep /^Makefile\.PL$/, $mpldh->read; - $mpldh->close; + foreach ($dh->read) { + $mpl_exists = /^Makefile\.PL$/; + $bpl_exists = /^Build\.PL$/; + } + $dh->close; } - unless ($mpl_exists) { + + # If this is a module that uses Module::Build then we need to + # install Module::Build. However, Module::Build uses _itself_ to + # install so to avoid a recursive prereq follow of doom, we + # explicitly do not try to install Module::Build when already + # install Module::Build. - Dave Rolsky + if ($bpl_exists and not grep { $_ eq "Module::Build" } $self->containsmods) { + my $nmo = $CPAN::META->instance("CPAN::Module","Module::Build"); + + unless ($nmo->inst_file and $nmo->uptodate) { + $CPAN::Frontend->myprint("The module you are installing requires the Module::Build package. +Either you do not have this module installed or you do not have the latest version. +It is recommended that you install the latest version now or +else it may not be possible to install this module"); + $self->follow_prereqs("Module::Build"); + } + } + + unless ($mpl_exists or $bpl_exists) { $self->debug(sprintf("makefilepl[%s]anycwd[%s]", $mpl, CPAN::anycwd(), @@ -3987,7 +4010,7 @@ $self->{'configure'} = $configure; } elsif (-f File::Spec->catfile($packagedir,"Makefile")) { $CPAN::Frontend->myprint(qq{ -Package comes with a Makefile and without a Makefile.PL. +Package comes with a Makefile and without a Makefile.PL or Build.PL. We\'ll try to build it with that Makefile then. }); $self->{writemakefile} = "YES"; @@ -4000,9 +4023,9 @@ } $cf =~ s|[/\\:]||g; # risk of filesystem damage $cf = "unknown" unless length($cf); - $CPAN::Frontend->myprint(qq{Package seems to come without Makefile.PL. - (The test -f "$mpl" returned false.) - Writing one on our own (setting NAME to $cf)\a\n}); + $CPAN::Frontend->myprint(qq{Package seems to come without Makefile.PL or Build.PL. + (The tests -f "$mpl" and -f "$bpl" returned false.) + Writing a Makefile.PL on our own (setting NAME to $cf)\a\n}); $self->{had_no_makefile_pl}++; sleep 3; @@ -4013,7 +4036,7 @@ or Carp::croak("Could not open >$mpl: $!"); $fh->print( qq{# This Makefile.PL has been autogenerated by the module CPAN.pm -# because there was no Makefile.PL supplied. +# because there was no Makefile.PL or Build.PL supplied. # Autogenerated on: }.scalar localtime().qq{ use ExtUtils::MakeMaker; @@ -4021,9 +4044,14 @@ }); $fh->close; + + $mpl_exists = 1; } } + $self->{makescript} = $mpl_exists ? "Makefile.PL" : $bpl_exists ? "Build.PL" : ""; + $self->{maketype} = $mpl_exists ? 'make' : $bpl_exists ? "Module::Build" : ""; + return $self; } @@ -4486,7 +4514,7 @@ # $switch = "-MExtUtils::MakeMaker ". # "-Mops=:default,:filesys_read,:filesys_open,require,chdir" # if $] > 5.00310; - $system = "$perl $switch Makefile.PL $CPAN::Config->{makepl_arg}"; + $system = "$perl $switch $self->{makescript} $CPAN::Config->{makepl_arg}"; } unless (exists $self->{writemakefile}) { local($SIG{ALRM}) = sub { die "inactivity_timeout reached\n" }; @@ -4523,16 +4551,17 @@ } else { $ret = system($system); if ($ret != 0) { - $self->{writemakefile} = "NO Makefile.PL returned status $ret"; + $self->{writemakefile} = "NO $self->{makescript} returned status $ret"; return; } } - if (-f "Makefile") { + if (($self->{maketype} eq "make" && -f "Makefile") || + ($self->{maketype} eq "Module::Build" && -f "Build")) { $self->{writemakefile} = "YES"; delete $self->{make_clean}; # if cleaned before, enable next } else { $self->{writemakefile} = - qq{NO Makefile.PL refused to write a Makefile.}; + qq{NO $self->{makescript} refused to write a Makefile/Build.PL.}; # It's probably worth it to record the reason, so let's retry # local $/; # my $fh = IO::File->new("$system |"); # STDERR? STDIN? @@ -4546,7 +4575,11 @@ if (my @prereq = $self->unsat_prereq){ return 1 if $self->follow_prereqs(@prereq); # signal success to the queuerunner } - $system = join " ", $CPAN::Config->{'make'}, $CPAN::Config->{make_arg}; + if ($self->{maketype} eq 'make') { + $system = join " ", $CPAN::Config->{'make'}, $CPAN::Config->{make_arg}; + } else { + $system = join " ", $self->perl, File::Spec->catfile( File::Spec->curdir, "Build" ), $CPAN::Config->{make_arg}; + } if (system($system) == 0) { $CPAN::Frontend->myprint(" $system -- OK\n"); $self->{'make'} = "YES"; @@ -4649,6 +4682,7 @@ # but we must have run it my $build_dir = $self->{build_dir} or die "Panic: no build_dir?"; my $makefile = File::Spec->catfile($build_dir,"Makefile"); + my $buildprereq = File::Spec->catfile($build_dir,"_build","prereq"); my(%p) = (); my $fh; if (-f $makefile @@ -4677,6 +4711,16 @@ } last; } + } elsif (-f $buildprereq + and + $fh = FileHandle->new("<$buildprereq")) { + while (<$fh>) { + my ($mod,$ver) = split /\s*=\s*/; + if ( defined $p{$mod} ) { + warn "Warning: PREREQ_PM mentions $mod more than once, last mention wins"; + } + $p{$mod} = $ver; + } } $self->{prereq_pm_detected}++; return $self->{prereq_pm} = \%p; @@ -4725,7 +4769,12 @@ local $ENV{PERL5LIB} = $ENV{PERL5LIB} || ""; $CPAN::META->set_perl5lib; - my $system = join " ", $CPAN::Config->{'make'}, "test"; + my $system; + if ($self->{maketype} eq "make") { + $system = join " ", $CPAN::Config->{'make'}, "test"; + } elsif ($self->{maketype} eq "Module::Build") { + $system = join " ", $self->perl, File::Spec->catfile( File::Spec->curdir, "Build" ), "test"; + } if (system($system) == 0) { $CPAN::Frontend->myprint(" $system -- OK\n"); $CPAN::META->is_tested($self->{'build_dir'}); @@ -4757,7 +4806,12 @@ return; } - my $system = join " ", $CPAN::Config->{'make'}, "clean"; + my $system; + if ($self->{maketype} eq "make") { + $system = join " ", $CPAN::Config->{'make'}, "clean"; + } elsif ($self->{maketype} eq "Module::Build") { + $system = join " ", $self->perl, File::Spec->catfile( File::Spec->curdir, "Build" ), "clean"; + } if (system($system) == 0) { $CPAN::Frontend->myprint(" $system -- OK\n"); @@ -4832,8 +4886,14 @@ return; } - my $system = join(" ", $CPAN::Config->{'make'}, - "install", $CPAN::Config->{make_install_arg}); + my $system; + if ($self->{maketype} eq "make") { + $system = join(" ", $CPAN::Config->{'make'}, + "install", $CPAN::Config->{make_install_arg}); + } elsif ($self->{maketype} eq "Module::Build") { + $system = join(" ", $self->perl, File::Spec->catfile( File::Spec->curdir, "Build" ), + "install", $CPAN::Config->{make_install_arg}); + } my($stderr) = $^O =~ /Win/i ? "" : " 2>&1 "; my($pipe) = FileHandle->new("$system $stderr |"); my($makeout) = ""; |
|
From: Ken W. <ke...@ma...> - 2003-09-21 17:56:18
|
On Sunday, September 21, 2003, at 09:51 AM, Steve Purkis wrote: > On Friday, September 19, 2003, at 07:12 pm, Ken Williams wrote: > >> [snip!] >> * The thing that would probably make the most practical difference >> here is to patch CPAN.pm so that it supports Module::Build. This >> won't be too difficult, and many people do keep CPAN up to date more >> diligently than they do with other modules. > > Yes, but until that time it makes sense for module authors to use the > backwards compatibility layer and generate a Makefile.PL. Indeed. Dave, do you suppose you could revive the CGI.pm patch? > Still, as a module author I think this feature is well documented. If > anything, perhaps a small emphasis on using "create_makefile_pl => > 'passthrough'" could be made? Yeah, or I suppose I could just not make any recommendation at all and make sure people know what their options are. When I think of various other recommendations in the perl documentation I tend to disagree with them, or think them presumptuous. -Ken |
|
From: Steve P. <sp...@qu...> - 2003-09-21 14:51:59
|
On Friday, September 19, 2003, at 07:12 pm, Ken Williams wrote: > [snip!] > * The thing that would probably make the most practical difference > here is to patch CPAN.pm so that it supports Module::Build. This > won't be too difficult, and many people do keep CPAN up to date more > diligently than they do with other modules. Yes, but until that time it makes sense for module authors to use the backwards compatibility layer and generate a Makefile.PL. Still, as a module author I think this feature is well documented. If anything, perhaps a small emphasis on using "create_makefile_pl => 'passthrough'" could be made? -Steve |
|
From: Ken W. <ke...@ma...> - 2003-09-21 14:18:15
|
On Sunday, September 21, 2003, at 12:56 AM, Dave Rolsky wrote: > On Sat, 20 Sep 2003, Ken Williams wrote: > >> Oh, we don't use the patch tracker on sf.net (and there's no patch >> attached to that item either). Unfortunately we can't shut off the >> portions of sf.net we're not using. > > Yeah, you can. There's an admin section. > Oh, thanks - I've disabled the public view of the 4 trackers. -Ken |
|
From: Dave R. <au...@ur...> - 2003-09-21 05:56:30
|
On Sat, 20 Sep 2003, Ken Williams wrote: > Oh, we don't use the patch tracker on sf.net (and there's no patch > attached to that item either). Unfortunately we can't shut off the > portions of sf.net we're not using. Yeah, you can. There's an admin section. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-09-21 02:07:07
|
On Saturday, September 20, 2003, at 08:34 PM, Jochen Wiedmann wrote: > Ken Williams wrote: > >> What patch is that? I don't see it on rt.cpan.org or in the mailing >> list archives. > > It's on sf.net, of course. Oh, we don't use the patch tracker on sf.net (and there's no patch attached to that item either). Unfortunately we can't shut off the portions of sf.net we're not using. In any case, this has been available in Module::Build since at least version 0.19, using two different equivalent syntaxes: perl Build.PL --config foo=bar --config baz=quux perl Build.PL config=foo=bar config=baz=quux The first syntax appeared in version 0.19, the second has been around much longer (I'm not sure exactly how long). There's no central place in the documentation that explains the syntax of command line arguments, but I'd welcome a patch that did so in a coherent way. -Ken |
|
From: Jochen W. <jo...@is...> - 2003-09-21 01:34:32
|
Ken Williams wrote: > What patch is that? I don't see it on rt.cpan.org or in the mailing > list archives. It's on sf.net, of course. Jochen |
|
From: Ken W. <ke...@ma...> - 2003-09-21 00:49:28
|
On Saturday, September 20, 2003, at 03:18 PM, Jochen Wiedmann wrote: > > Hi, > > any reason, why patch 690651 has got no response since 6 months or so? What patch is that? I don't see it on rt.cpan.org or in the mailing list archives. -Ken |
|
From: Jochen W. <jo...@is...> - 2003-09-20 20:17:22
|
Hi, any reason, why patch 690651 has got no response since 6 months or so? Regards, Jochen |
|
From: Ken W. <ke...@ma...> - 2003-09-20 14:21:10
|
On Friday, September 19, 2003, at 01:40 PM, Ken Y. Clark wrote:
> All,
>
> I wrote a couple weeks ago about this annoying warning:
>
> * WARNING: Configuration was initially created with '/usr/bin/perl',
> but we are now using '/usr/local/bin/perl'.
>
> I finally took a couple minutes to look at the source, and I see that
> the "Build" script uses $Config{'startperl'} for the shebang, but most
> everything else looks for Module::Build::Base->find_perl_interpreter.
> The following patch fixes that.
Hi Ken,
Thanks for the patch. I'll actually apply it in a different form,
because the 'startperl' entry may often contain much weirder stuff on
non-unix platforms. Here's how I'll apply:
Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.195
diff -u -r1.195 Base.pm
--- lib/Module/Build/Base.pm 19 Sep 2003 16:48:26 -0000 1.195
+++ lib/Module/Build/Base.pm 20 Sep 2003 14:19:52 -0000
@@ -719,6 +719,8 @@
}
}
+sub _startperl { shift()->{config}{startperl} }
+
sub print_build_script {
my ($self, $fh) = @_;
@@ -733,9 +735,10 @@
}
my $quoted_INC = join ",\n", map " '$_'", @myINC;
+ my $shebang = $self->_startperl;
print $fh <<EOF;
-$self->{config}{startperl}
+$shebang
BEGIN {
\$^W = 1; # Use warnings
Index: lib/Module/Build/Platform/Unix.pm
===================================================================
RCS file:
/cvsroot/module-build/Module-Build/lib/Module/Build/Platform/Unix.pm,v
retrieving revision 1.2
diff -u -r1.2 Unix.pm
--- lib/Module/Build/Platform/Unix.pm 9 Jun 2002 05:45:08 -0000 1.2
+++ lib/Module/Build/Platform/Unix.pm 20 Sep 2003 14:19:52 -0000
@@ -18,6 +18,12 @@
$self->do_system("$gzip '$dir.tar'");
}
+sub _startperl {
+ my ($self) = @_;
+ my $perl = $self->find_perl_interpreter or warn "Can't find your
perl interpreter";
+ return "#! $perl";
+}
+
1;
__END__
|
|
From: Ken W. <ke...@ma...> - 2003-09-19 20:07:46
|
Hi Ben, Thanks for forwarding this message here, I wanted to make sure anyone with an opinion got a chance to express it. A few thoughts of my own: * I think you assume I'm trying to switch everyone over to Module::Build. I'm not. I'm trying to provide an alternate installation mechanism that's better than MakeMaker. Whether an author switches is their own decision. If I can make it attractive enough (with the carrot, not the stick) for people to gain something out of the switch, then that's good. * Since I do think most people will be happier using Module::Build than MakeMaker, I want to try to increase its mindshare in the community. For many people (the same people you mention who don't keep up with the latest "cool stuff" discussions), the only way they'd hear about the project is if they have to install it when some module uses it. * The thing that would probably make the most practical difference here is to patch CPAN.pm so that it supports Module::Build. This won't be too difficult, and many people do keep CPAN up to date more diligently than they do with other modules. Of course, if the prevailing opinion is different than my own, I'll change the docs. When I read the thread on perlmonks though, it seems like most people weren't too upset at the omission of a Makefile.PL. -Ken Begin forwarded message: > From: "Benjamin J. Tilly " <ben...@op...> > Date: Thu Sep 18, 2003 2:42:59 PM US/Central > To: mod...@li... > Subject: [Module-build-general] Fw: Re: Module::Build::Compat should > not recommend not having a Makefile.PL > > I am forwarding this message as requested by Ken. I am not on the > Module::Build list, so please keep me in the CC list. > > My perspective is that CPAN authors should make at least a token nod > towards attempting to be compatible with existing installations. For > the forseeable future a significant fraction of the installed Perl > base will be using versions of Perl and CPAN which will break if > Makefile.PL is not present. Attempting to force them to change that > decision (which may be made for many reasons, and at many sites is > NOT a programmer-level decision) will create a certain level of > knee-jerk resentment and ill-will. I see no good reason to encourage > this kind of problem. My opinion is that attempts to shove a better > way down people's throats is a good way to feel like you really tried > while accomplishing negative work. > > Speaking personally, when there is an accepted standard way of doing > things, I tend to look with extreme suspicion on anyone who tells me > that I need to do things their own, newfangled way. It would not be > inaccurate to read that as, "I reject them out of hand until someone I > trust tells me to reconsider." I believe that this approach is fairly > common. And it is what I did when I heard about Module::Build. > > But now that I have reconsidered it, I can see benefits of using > Module::Build. I intend to update my handful of modules to use it as a > convenience to potential Windows users. However I see no reason to > penalize people who aren't playing with the latest shiny toys, and so > will use the backwards compatibility tool. And I would encourage > others to do the same. > > In short, encouraging people to use Module::Build and > Module::Build::Compat so that their modules will install easily for the > widest range of possible users seems like an effective way to advocate > Module::Build. Encouraging arguments by trying to break people who > have > not been following the latest "cool stuff" discussions in the Perl > world > is an effective way to leave bad tastes in people's mouths. Therefore > I > think that it would be good if Module::Build::Compat's documentation > and > Module::Build's proponent's advocacy recommended that authors try to do > what will be compatible with the largest number of possible users. > > Regards, > Ben > > ----- Original Message ----- > From: Ken Williams <ke...@ma...> > Date: Thu, 18 Sep 2003 10:20:05 -0500 > To: "Benjamin J. Tilly " <ben...@op...> > Subject: Re: Module::Build::Compat should not recommend not having a > Makefile.PL > >> Hi Ben, >> >> Could you send a message (or forward this one) to the Module::Build >> list, mod...@li... , so that we could >> discuss the matter? I'm inclined to keep the recommendation the same >> way I have it and to work on patching CPAN.pm, but if more others feel >> differently I could be persuaded otherwise. >> >> -Ken >> >> On Thursday, September 18, 2003, at 07:29 AM, Benjamin J. Tilly >> wrote: >> >>> While I appreciate that Module::Build was a lot of work and is trying >>> to >>> solve an important problem (making it simple to build standard Perl >>> modules on non-Unixy platforms), it will cause problems if module >>> authors break backwards compatibility with the vast majority of >>> current >>> users of CPAN, and it is counterproductive to encourage them to do >>> so. >>> >>> Therefore please modify the documentation for Module::Build::Compat >>> to >>> have it stop discouraging people from using it to get backwards >>> compatibility with the existing installed base. >>> >>> For more on this see the discussion starting at >>> http://www.perlmonks.org/index.pl?node_id=292164. (This email is the >>> one >>> that I said I would send at >>> http://www.perlmonks.org/index.pl?node_id=292366.) >>> >>> Ben >> > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Module-build-general mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/module-build-general |
|
From: Ken Y. C. <kc...@lo...> - 2003-09-19 19:56:53
|
All,
I wrote a couple weeks ago about this annoying warning:
* WARNING: Configuration was initially created with '/usr/bin/perl',
but we are now using '/usr/local/bin/perl'.
I finally took a couple minutes to look at the source, and I see that
the "Build" script uses $Config{'startperl'} for the shebang, but most
everything else looks for Module::Build::Base->find_perl_interpreter.
The following patch fixes that.
ky
*** Base.pm.orig Fri Sep 19 13:33:14 2003
--- Base.pm Fri Sep 19 13:31:43 2003
***************
*** 713,720 ****
my $quoted_INC = join ",\n", map " '$_'", @myINC;
print $fh <<EOF;
! $self->{config}{startperl}
BEGIN {
\$^W = 1; # Use warnings
--- 713,723 ----
my $quoted_INC = join ",\n", map " '$_'", @myINC;
+ my $perl = $self->find_perl_interpreter
+ or warn "Warning: Can't locate your perl binary";
+
print $fh <<EOF;
! #!$perl
BEGIN {
\$^W = 1; # Use warnings
|
|
From: Benjamin J. T. <ben...@op...> - 2003-09-18 19:45:47
|
I am forwarding this message as requested by Ken. I am not on the Module::Build list, so please keep me in the CC list. My perspective is that CPAN authors should make at least a token nod towards attempting to be compatible with existing installations. For the forseeable future a significant fraction of the installed Perl base will be using versions of Perl and CPAN which will break if Makefile.PL is not present. Attempting to force them to change that decision (which may be made for many reasons, and at many sites is NOT a programmer-level decision) will create a certain level of knee-jerk resentment and ill-will. I see no good reason to encourage this kind of problem. My opinion is that attempts to shove a better way down people's throats is a good way to feel like you really tried while accomplishing negative work. Speaking personally, when there is an accepted standard way of doing things, I tend to look with extreme suspicion on anyone who tells me that I need to do things their own, newfangled way. It would not be inaccurate to read that as, "I reject them out of hand until someone I trust tells me to reconsider." I believe that this approach is fairly common. And it is what I did when I heard about Module::Build. But now that I have reconsidered it, I can see benefits of using Module::Build. I intend to update my handful of modules to use it as a convenience to potential Windows users. However I see no reason to penalize people who aren't playing with the latest shiny toys, and so will use the backwards compatibility tool. And I would encourage others to do the same. In short, encouraging people to use Module::Build and Module::Build::Compat so that their modules will install easily for the widest range of possible users seems like an effective way to advocate Module::Build. Encouraging arguments by trying to break people who have not been following the latest "cool stuff" discussions in the Perl world is an effective way to leave bad tastes in people's mouths. Therefore I think that it would be good if Module::Build::Compat's documentation and Module::Build's proponent's advocacy recommended that authors try to do what will be compatible with the largest number of possible users. Regards, Ben ----- Original Message ----- From: Ken Williams <ke...@ma...> Date: Thu, 18 Sep 2003 10:20:05 -0500 To: "Benjamin J. Tilly " <ben...@op...> Subject: Re: Module::Build::Compat should not recommend not having a Makefile.PL > Hi Ben, > > Could you send a message (or forward this one) to the Module::Build > list, mod...@li... , so that we could > discuss the matter? I'm inclined to keep the recommendation the same > way I have it and to work on patching CPAN.pm, but if more others feel > differently I could be persuaded otherwise. > > -Ken > > On Thursday, September 18, 2003, at 07:29 AM, Benjamin J. Tilly wrote: > > > While I appreciate that Module::Build was a lot of work and is trying > > to > > solve an important problem (making it simple to build standard Perl > > modules on non-Unixy platforms), it will cause problems if module > > authors break backwards compatibility with the vast majority of current > > users of CPAN, and it is counterproductive to encourage them to do so. > > > > Therefore please modify the documentation for Module::Build::Compat to > > have it stop discouraging people from using it to get backwards > > compatibility with the existing installed base. > > > > For more on this see the discussion starting at > > http://www.perlmonks.org/index.pl?node_id=292164. (This email is the > > one > > that I said I would send at > > http://www.perlmonks.org/index.pl?node_id=292366.) > > > > Ben > |
|
From: Ken W. <ke...@ma...> - 2003-09-16 18:57:24
|
Hi Dennis, You're quite right, the dimensions of "recommended vs. required vs. conflicts" and "build vs. test" should really be independent. The next major issue for us to sort out in M::B is that of dependencies. I've just added an item to the TODO file for it. I'm a little hesitant to add much support for build_recommends before the larger issues are resolved. It might be good enough for you to just not mention Struct::Compare in your prerequisites for now, and just use it if it's present? -Ken On Wednesday, September 10, 2003, at 02:20 PM, Dennis Sutch wrote: > Would it be possible to include a build_recommends argument for the > new() > method? > > I have a module which optionally uses the module Struct::Compare in > build > tests, if that module is found. This module really shouldn't be > designated as "build_requires", since it is not necessary for the > build. |
|
From: Steve P. <sp...@qu...> - 2003-09-15 18:03:24
|
On Monday, September 15, 2003, at 06:15 pm, Ken Williams wrote: > On Monday, September 15, 2003, at 11:03 AM, Steve Purkis wrote: > >> Hi all, >> >> When you update the 'dist_version_from' file *after* running >> Build.PL, the 'dist' action builds a tarball for the old version >> (which seems wrong to me). Perhaps it should check for a new >> $VERSION and rebuild the cache if it has changed? >> > > Yeah, this is known behavior (though perhaps not to anyone but me?). > The Build.PL step solidifies various configuration information, then > the subsequent steps do everything based on this configuration. I've noticed that - for example if a Build.PL ever changes, running ./Build <whatever> doesn't trigger a rebuild of the Build script like MakeMaker's Makefiles did. > I think you're probably right about the solution, though I think maybe > the user should have to manually do the update after we give a > warning. Otherwise we may end up losing any parameters the user > specified to the Build.PL invocation. > > Or we could just change the version number itself, and nothing else, > in the cache. Which makes me think maybe we shouldn't cache it there > at all... I prefer the warning option, mainly because a general solution to it will prolly cover other cases we haven't though of. And also, it makes sense to me for the version number to be in the cache. So how's about this rule: Generate a warning whenever Build.PL or a dependency changes. This also opens up the option of a 'rebuild_on_modify' flag to the constructor. Though I'm still out to lunch as to whether or not that would be useful... :) -Steve |
|
From: Ken W. <ke...@ma...> - 2003-09-15 17:15:34
|
On Monday, September 15, 2003, at 11:03 AM, Steve Purkis wrote: > Hi all, > > When you update the 'dist_version_from' file *after* running Build.PL, > the 'dist' action builds a tarball for the old version (which seems > wrong to me). Perhaps it should check for a new $VERSION and rebuild > the cache if it has changed? > Yeah, this is known behavior (though perhaps not to anyone but me?). The Build.PL step solidifies various configuration information, then the subsequent steps do everything based on this configuration. I think you're probably right about the solution, though I think maybe the user should have to manually do the update after we give a warning. Otherwise we may end up losing any parameters the user specified to the Build.PL invocation. Or we could just change the version number itself, and nothing else, in the cache. Which makes me think maybe we shouldn't cache it there at all... -Ken |
|
From: Steve P. <sp...@qu...> - 2003-09-15 16:09:08
|
Hi all, When you update the 'dist_version_from' file *after* running Build.PL, the 'dist' action builds a tarball for the old version (which seems wrong to me). Perhaps it should check for a new $VERSION and rebuild the cache if it has changed? -Steve |
|
From: Ken W. <ke...@ma...> - 2003-09-15 15:30:00
|
On Sunday, September 14, 2003, at 08:57 PM, Mark Stosberg wrote: > > I've noticed that a number of Perl modules have a README file that > repeats the contents of the primary modules documentation in a text > based format. This seems reasonable to me. [...] > If this seems like a common and useful thing that people would want to > do with > Module::Build, perhaps it could warrant syntax shortcut. Hi Mark, This has already been added to the CVS version of Module::Build, with a simple 'create_readme' parameter passed to the new() method. -Ken |
|
From: Mark S. <ma...@su...> - 2003-09-15 01:57:25
|
Hello,
I've noticed that a number of Perl modules have a README file that
repeats the contents of the primary modules documentation in a text
based format. This seems reasonable to me.
[ Puts on thinking cap for a moment. ]. A bit of reflection generated a
couple important thoughts about this:
1. Portability doesn't matter for users in this case, just other
developers who do "Make dist".
2. Here's a syntax that should be portable, using Pod::Text:
use Module::Build;
my $class = Module::Build->subclass(
class => 'CGI::Session::PureSQL::Builder',
code => q{
sub ACTION_dist {
my $self = shift;
use Pod::Text;
my $parser = Pod::Text->new;
$parser->parse_from_file('./lib/CGI/Session/PureSQL.pm', 'README');
$self->SUPER::ACTION_dist;
}
},
);
$class->new(
module_name => 'CGI::Session::PureSQL',
license => 'perl',
)->create_build_script;
####
If this seems like a common and useful thing that people would want to do with
Module::Build, perhaps it could warrant syntax shortcut.
Mark
--
http://mark.stosberg.com/
|
|
From: Ken W. <ke...@ma...> - 2003-09-13 15:30:32
|
On Saturday, September 13, 2003, at 03:29 AM, Ed Avis wrote: > What is the connection between Module::Build and Module::Install? > The documentation > <http://search.cpan.org/author/KWILLIAMS/Module-Build-0.20_01/lib/ > Module/Build.pm> > says: > >> If you want the installation process to look around in @INC for other >> versions of the stuff you're installing and try to delete it, you can >> use the uninst parameter, which tells Module::Install to do so: > > but doesn't mention that module anywhere else. > Oops, sorry, that's an error - it should have said ExtUtils::Install. I'll fix it. Module::Build currently knows nothing about Module::Install. I think Module::Install may know something about Module::Build, but I'm not sure. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-09-13 15:26:11
|
On Friday, September 12, 2003, at 09:06 PM, Michael G Schwern wrote: > On Fri, Sep 12, 2003 at 02:48:35PM -0500, Ken Williams wrote: >> You're reading my mind! Earlier this week I committed a patch adding >> a >> "create_readme" parameter, which uses the file in dist_version_from to >> generate a README using pod2html. Will you need more flexibility than >> that? > > pod2html? By all that is 7bit ASCII I hope you meant Pod::Text. Oh, indeed - it's Pod::Text. -Ken |
7 messages has been excluded from this view by a project administrator.
