module-build-general Mailing List for Module::Build (Page 179)
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: <sc...@po...> - 2003-02-17 21:56:04
|
On Mon, Feb 17, 2003 at 03:20:27PM -0600, Ken Williams wrote: > Right. So this is just a more cross-platform way to do > > $^X -e "unlink shift" $makefile Double quotes are surprsingly cross platform. Just have to watch out for Unix interpolation. > The only part of it that's still an issue, I think, is the $^X > variable. It might contain something like "/My Computer/foo/bar/perl", > in which case I guess the shell invocation would think the command was > "/My" with argument "Computer/foo/bar/perl". Heh. Good luck. I gave up on that. nmake is particularly frustrating and brain dead about having any sane quoting rules for it. My attempt at a cross-platform perl one-liner generating tool is: ExtUtils::MM_Any->oneliner in 6.06_02. I mostly gave up on trying to deal with paths to perl with spaces in it. |
|
From: Ken W. <ke...@ma...> - 2003-02-17 21:20:39
|
On Monday, February 17, 2003, at 01:17 PM, sc...@po... wrote: > On Mon, Feb 17, 2003 at 12:18:00PM -0600, Dave Rolsky wrote: >>> $^X -e unlink -e shift $makefile >> >> unlink -e ??? > > He's avoiding using quotes. You're allowed to have multiple -e's on > the > command line. They'll be joined with a space and run as a single > program. Right. So this is just a more cross-platform way to do $^X -e "unlink shift" $makefile The only part of it that's still an issue, I think, is the $^X variable. It might contain something like "/My Computer/foo/bar/perl", in which case I guess the shell invocation would think the command was "/My" with argument "Computer/foo/bar/perl". -Ken |
|
From: Ken W. <ke...@ma...> - 2003-02-17 20:09:42
|
On Monday, February 17, 2003, at 01:41 PM, Brian Ingerson wrote: > Not necessarily. It can create both the Makefile and the Build script, > and then cue the user what to do, especially on non-unix systems. > Okay, that sounds reasonable. > It's a good experiment actually. Module::Build and Test::More are two > excellent modules that I will probably not use because of the "prereq > syndrome". I won't add prerequisites to a module unless it is crucial > to > that module's behaviour. And while useful, M::B and T::M are not > crucial. Sometimes they are crucial for some projects. For example, some of my modules have "recommended" dependencies that I can't express well using MakeMaker. Crypt::SKey needs either Digest::MD4 *or* Digest::MD5, and it can optionally use Term::ReadKey to function as a simple SKey command-line calculator. But the module can be useful with only Digest::MD4, for example, so using M::B's more flexible prerequisite system means that the user will actually have *fewer* required prereqs than under MakeMaker, even if they don't already have M::B installed. Then there are the cases where in order to get something installed correctly, I just can't manage to do the job properly using EU::MM, so I have to turn to M::B. For many of my modules, I've been distributing with both a Makefile.PL and a Build.PL, and before too long I'll probably turn the Makefile.PLs into pass-throughs when it gets too hectic for me to manage both of them. But I won't do that for crucial modules until M::B is more well-known and more widely distributed and tested. > And I won't have to worry about what versions of T::M and M::B support > my module's needs because "Hey, it worked on my system, it almost > certainly will work everywhere else, because it's the exact same > version." And what of the people who have been sending me bug reports that say that M::B doesn't work right on Win32, even though I tested it fine on my iBook? Maybe at some future date we'll be able to make modules that a) have no unspotted bugs, and b) have no cross-platform issues, but I don't think we're there yet. > If a later version of M::B or T::M is incompatible or broken, it will > have absolutely no effect on that module I wrote 10 years ago before I > left the Perl community altogether to pursue a fulltime career in Pizza > Delivery Management. So, which do you think is more common: a) an unseen bug in a module gets fixed in a future version, or b) a module with no bugs gets broken in a future version? I'd say it's a), and that CP::MM (as described, at least) optimizes for the less common case instead of the more common one, in a way that would annoy me as a developer or system maintainer. I think that in the CP::MM project, it will be *crucial* to allow the user to use an upgraded version of a module that they've installed more recently than the one the developer provided in the bundle, for the reasons I described above. It's really just not true that "it worked once for the developer" implies that "it will work for everyone else now and forever". Usually the way people deal with buggy code on their systems is to upgrade things using bug-fix releases, but if you keep distributing buggy versions cached in CPAN distros people are going to be awfully upset. -Ken |
|
From: Brian I. <in...@tt...> - 2003-02-17 19:41:39
|
On 17/02/03 12:08 -0600, Ken Williams wrote:
>
> On Sunday, February 16, 2003, at 01:35 PM, Brian Ingerson wrote:
> > I went to the talk. It got me to thinking about CPAN::MakeMaker and its
> > relationship to Module::Build.
> >
> > Given:
> >
> > The goal of CP::MM is to allow authors to write very simple/clean
> > Makefile.PLs that can potentially "turn on" very powerful features
> > like "bundling" with the flick of a switch.
> >
> > The Makefile.PL produces a Makefile.
> >
> > Then:
> >
> > There is no reason why CP::MM can't produce a Makefile that wraps
> > Module::Build!
>
> I'm not sure that's ideal, because it still requires 'make' to
> orchestrate at least some of the process.
Not necessarily. It can create both the Makefile and the Build script,
and then cue the user what to do, especially on non-unix systems.
> One of the hairiest parts of
> Module::Build is the tiny little pass-through Makefile in
> Module::Build::Compat, because it has to work in all kinds of different
> environments. I've just made a bunch of changes that let it work on
> Windows, but there are still a bunch of things missing, like
> translating MM command-line options to M::B options
>
>
> > If the author has a version of Module::Build on there system that
> > is sufficient to handle the options that the author has requested
> > of CPAN::MakeMaker, then CP::MM will (optionally??) bundle M::B
> > into the author's dist. After that nobody is the wiser. Everything
> > just works.
>
> I wouldn't want lots of installation tools bundled into all my
> distributions, though. I still think it's far better to have a
> powerful system for listing dependencies in as fine-grained and
> accessible a manner as is necessary, and let the user choose their
> favorite policies and tools for fulfilling those dependencies.
It's a good experiment actually. Module::Build and Test::More are two
excellent modules that I will probably not use because of the "prereq
syndrome". I won't add prerequisites to a module unless it is crucial to
that module's behaviour. And while useful, M::B and T::M are not
crucial.
On the other hand, if I can just create a Makefile.PL like this:
use CPAN::MakeMaker;
WriteMakefile;
and have it do all the right things with no added prereqs, well
fantastic. If it adds a few kilos to my tarball I certainly won't sweat
it.
M::B modules minus the Pod doc is 12kb as a tar.gz.
---
And I won't have to worry about what versions of T::M and M::B support
my module's needs because "Hey, it worked on my system, it almost
certainly will work everywhere else, because it's the exact same
version."
If a later version of M::B or T::M is incompatible or broken, it will
have absolutely no effect on that module I wrote 10 years ago before I
left the Perl community altogether to pursue a fulltime career in Pizza
Delivery Management.
Cheers, Brian
|
|
From: <sc...@po...> - 2003-02-17 19:17:16
|
On Mon, Feb 17, 2003 at 12:18:00PM -0600, Dave Rolsky wrote: > > $^X -e unlink -e shift $makefile > > unlink -e ??? He's avoiding using quotes. You're allowed to have multiple -e's on the command line. They'll be joined with a space and run as a single program. |
|
From: Dave R. <au...@ur...> - 2003-02-17 18:19:09
|
On Mon, 17 Feb 2003, Ken Williams wrote:
> Hi,
>
> After some discussions with James Freeman, I've just checked in the
> following code that generates the pass-through Makefile:
>
> sub fake_makefile {
> my $makefile = $_[1];
> my $build = File::Spec->catfile( '.', 'Build' );
>
> return <<"EOF";
> all :
> $build
> realclean :
> $build realclean
> $^X -e unlink -e shift $makefile
unlink -e ???
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
|
|
From: Ken W. <ke...@ma...> - 2003-02-17 18:09:24
|
On Sunday, February 16, 2003, at 01:35 PM, Brian Ingerson wrote: > I went to the talk. It got me to thinking about CPAN::MakeMaker and its > relationship to Module::Build. > > Given: > > The goal of CP::MM is to allow authors to write very simple/clean > Makefile.PLs that can potentially "turn on" very powerful features > like "bundling" with the flick of a switch. > > The Makefile.PL produces a Makefile. > > Then: > > There is no reason why CP::MM can't produce a Makefile that wraps > Module::Build! I'm not sure that's ideal, because it still requires 'make' to orchestrate at least some of the process. One of the hairiest parts of Module::Build is the tiny little pass-through Makefile in Module::Build::Compat, because it has to work in all kinds of different environments. I've just made a bunch of changes that let it work on Windows, but there are still a bunch of things missing, like translating MM command-line options to M::B options > If the author has a version of Module::Build on there system that > is sufficient to handle the options that the author has requested > of CPAN::MakeMaker, then CP::MM will (optionally??) bundle M::B > into the author's dist. After that nobody is the wiser. Everything > just works. I wouldn't want lots of installation tools bundled into all my distributions, though. I still think it's far better to have a powerful system for listing dependencies in as fine-grained and accessible a manner as is necessary, and let the user choose their favorite policies and tools for fulfilling those dependencies. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-02-17 18:01:54
|
On Sunday, February 9, 2003, at 11:19 PM, Ken Williams wrote: > > On Sunday, February 9, 2003, at 08:48 PM, Dave Rolsky wrote: > >> On Sun, 9 Feb 2003, Ken Williams wrote: >> >>>> Are you really sure? On my system, I copied >>>> /usr/local/share/perl/5.8.0/Module/Build/Base.pm to >>>> /usr/share/perl/5.8.0/Module/Build/Base.pm >>>> >>>> If I then changed Base.pm and did "./Build install uninst=1" it >>>> worked >>>> fine. >>> >>> >>> Well, it looks like my ExtUtils::Install is broken. I just did the >>> same thing under MakeMaker and it didn't work there either. I've got >>> version 1.31 of EU::I installed, which is the same as what's in the >>> EU::MM CVS repository right now. >> >> I have 1.30. That may explain it. > > Either that, or it's allergic to me. On a different machine with > EU::I 1.28, I get sporadic behavior. Note the 'ls' at the end of this > indicating at least one shadow file that should have been removed, but > only a couple of shadows were actually removed. I figured out what was happening. ExtUtils::Install only tells you about the shadow files that are actually *different*, so it can still leave a lot of duplicate files around on your system if you install first in one place and then in another. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-02-17 16:33:02
|
On Monday, February 17, 2003, at 10:20 AM, James Freeman wrote: > Hi Ken, > > It needs to be: > > perl <file> > > or in this case > > $^X $build Okay, I've made the change. Thanks for your help. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-02-17 15:45:53
|
Hi,
After some discussions with James Freeman, I've just checked in the
following code that generates the pass-through Makefile:
sub fake_makefile {
my $makefile = $_[1];
my $build = File::Spec->catfile( '.', 'Build' );
return <<"EOF";
all :
$build
realclean :
$build realclean
$^X -e unlink -e shift $makefile
.DEFAULT :
$build \$@
.PHONY : install manifest
EOF
}
It works fine for me, and it doesn't have any possibility of non-safe
shell characters anymore. Can someone test it (cvs update; perl
Makefile.PL; make test; make realclean) on other platforms besides OS
X? I'm particularly keen to know whether the 'realclean' target
succeeds in unlinking the Makefile on Win32, or whether it's considered
"open" and can't be deleted. If that's the case, I'll need a chmod()
or something before unlinking.
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-02-16 22:33:49
|
On Sunday, February 16, 2003, at 03:32 PM, Dave Rolsky wrote: > Ken, I think the prereq for this should 0.23. It's been fixed to work > on > Win32 and other platforms without problems. Okay, done. -Ken |
|
From: Dave R. <au...@ur...> - 2003-02-16 21:34:05
|
Ken, I think the prereq for this should 0.23. It's been fixed to work on Win32 and other platforms without problems. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-02-16 20:46:57
|
[moved to Module::Build list] > From: "Randy W. Sims" <Ra...@Th...> > Date: Sun Feb 16, 2003 2:33:12 PM US/Central > > Bug Report: > =========== > > M::B does not work on MSWin32. ;) Heh - okay, fair enough. =) > > It needs to do pretty much the same thing as the patched basic.t in > ParseXS. I'll make the modifications and test it out if you want? That would be great - the way to do this would be to give me a patch for lib/Module/Build/Platform/Windows.pm which overrides compile_c() and link_c() so that they work on Win32. You can find the latest version of Module::Build in CVS - please do patch against it, instead of version 0.15 on CPAN, because there have been significant changes since then. Details are at http://sourceforge.net/cvs/?group_id=45731 . -Ken |
|
From: Ken W. <ke...@ma...> - 2003-02-16 20:37:47
|
Begin forwarded message:
> From: "Randy W. Sims" <Ra...@Th...>
> Date: Sun Feb 16, 2003 2:33:12 PM US/Central
> To: Ken Williams <ke...@ma...>
> Cc: mak...@pe...
> Subject: Re: MakeMaker only looks for xsubpp in $Config{privlibexp}
>
> Hi Ken,
>
> I've done some more testing under windows, and corrected some problems
> in the test script for the Borland and MinGW compilers. I broke up
> some of the code in the test script into a couple of subroutines
> (do_compile & do_link) to clean up the mess I made in the main testing
> routine jumping through all those hoops to satisfy the 3 supported
> compilers on that platform...
>
> On 2/11/2003 11:02 PM, Ken Williams wrote:
>> On Tuesday, February 11, 2003, at 05:25 PM, Randy W. Sims wrote:
>>>
>>> ( It would be nice if there were a module specifically for invoking
>>> the compiler & linker. There are quite a few modules I can think of
>>> that would benifit from it. )
>> Absolutely. I've gotten surprisingly good results in Module::Build
>> with just straightforward system() calls, or at least people haven't
>> submitted bug reports. But it would be cool to abstract this away
>> somewhere.
>
> Bug Report:
> ===========
>
> M::B does not work on MSWin32. ;)
>
> It needs to do pretty much the same thing as the patched basic.t in
> ParseXS. I'll make the modifications and test it out if you want?
>
>>>> (I'd also like to fix the "Use of uninitialized value in join or
>>>> string at
>>>> /Users/ken/src/modules/ExtUtils-ParseXS/blib/lib/ExtUtils/
>>>> ParseXS.pm line 798, <File0000> line 14" error before 2.00, but I
>>>> don't know what's causing it.)
>>>
>>>
>>> I don't recall seeing that message. Do you see it when building a
>>> particular module?
>>>
>> I see it when running 'make test' for ExtUtils::ParseXS.
>
> I included a fix for this in the patch. The array @proto_arg will have
> an undefined slot in it when prototypes are requested and a subroutine
> is encounted that does not have any default parameters. That slot is
> reserved for the flag ( ';' - semicolon ) that indicates the start of
> the parms with defaults. (You can verify by changing the XS file so
> is_even has a default parm or changing the calls to process_file in
> the test script so that 'prototypes => 0') The fix is just to 'grep
> defined, @proto_arg'...
>
> The thing that puzzles me is that without 'use warnings' I would not
> expect to see that warning:
>
> $ perl -e "my @a=(undef,'blah');print join('',@a);"
> blah
>
> $ perl -we "my @a=(undef,'blah');print join('',@a);"
> Use of uninitialized value in join or string at -e line 1.
> blah
>
> Randy.
> diff -ur ExtUtils-ParseXS-1.99-orig/lib/ExtUtils/ParseXS.pm
> ExtUtils-ParseXS-1.99/lib/ExtUtils/ParseXS.pm
> --- ExtUtils-ParseXS-1.99-orig/lib/ExtUtils/ParseXS.pm 2003-02-15
> 03:47:24.000000000 -0500
> +++ ExtUtils-ParseXS-1.99/lib/ExtUtils/ParseXS.pm 2003-02-16
> 08:47:49.000000000 -0500
> @@ -795,7 +795,7 @@
> push @proto_arg, "$s\@"
> if $elipsis ;
>
> - $proto = join ("", @proto_arg);
> + $proto = join ("", grep(defined, @proto_arg));
> }
> else {
> # User has specified a prototype
> diff -ur ExtUtils-ParseXS-1.99-orig/t/basic.t
> ExtUtils-ParseXS-1.99/t/basic.t
> --- ExtUtils-ParseXS-1.99-orig/t/basic.t 2003-02-15 03:55:15.000000000
> -0500
> +++ ExtUtils-ParseXS-1.99/t/basic.t 2003-02-16 11:48:39.000000000 -0500
> @@ -16,10 +16,10 @@
>
> use Carp; $SIG{__WARN__} = \&Carp::cluck;
>
> -sub Is_MSVC { return $^O eq 'MSWin32'
> - && $Config{cc} =~ /cl(\.exe)?$/i
> - && $Config{ld} =~ /link(\.exe)?$/i
> -}
> +my $Is_MSWin32 = $^O eq 'MSWin32';
> +my $BCC = $Is_MSWin32 && $Config{cc} =~ /bcc32(\.exe)?$/;
> +my $MSVC = $Is_MSWin32 && $Config{cc} =~ /cl(\.exe)?$/;
> +my $MinGW = $Is_MSWin32 && $Config{cc} =~ /gcc(\.exe)?$/;
>
> #########################
>
> @@ -34,26 +34,12 @@
>
> # Try to compile the file! Don't get too fancy, though.
> if (have_compiler()) {
> - my $corelib = File::Spec->catdir($Config{archlib}, 'CORE');
> - my $o_file = "XSTest$Config{obj_ext}";
> - my $cc_out = Is_MSVC() ? '-Fo' : '-o ';
> -
> - ok !do_system("$Config{cc} -c $Config{ccflags} -I$corelib
> $cc_out$o_file XSTest.c");
> - ok -e $o_file, 1, "Make sure $o_file exists";
> -
> - my $lib_file = "XSTest.$Config{dlext}";
> - my $ld_out = '-o ';
> - my $libs = '';
> - if ( $^O eq 'MSWin32' ) {
> - require ExtUtils::Mksymlists;
> - Mksymlists( 'NAME' => 'XSTest', 'DLBASE' => 'XSTest', 'IMPORTS'
> => {} );
> -
> - if ( Is_MSVC() ) {
> - $ld_out = '-OUT:';
> - $libs = "$Config{libperl} -def:XSTest.def";
> - }
> - }
> - ok !do_system("$Config{shrpenv} $Config{ld} $Config{lddlflags}
> $ld_out$lib_file $o_file $Config{libs} $libs" );
> + my $module = 'XSTest';
> +
> + ok do_compile( $module );
> + ok -e $module.$Config{obj_ext}, 1, "Make sure $module exists";
> +
> + ok do_link( $module );
>
> eval {require XSTest};
> ok $@, '';
> @@ -69,7 +55,7 @@
> sub find_in_path {
> my $thing = shift;
> my @path = split $Config{path_sep}, $ENV{PATH};
> - my @exe_ext = $^O eq 'MSWin32' ?
> + my @exe_ext = $Is_MSWin32 ?
> split($Config{path_sep}, $ENV{PATHEXT} || '.com;.exe;.bat') :
> ('');
> foreach (@path) {
> @@ -94,6 +80,52 @@
> return 1;
> }
>
> +sub do_compile {
> + my $module = shift;
> + my $module_o = "$module$Config{obj_ext}";
> + my $corelib = File::Spec->catdir($Config{archlib}, 'CORE');
> + my $cc_out = $MSVC ? '-Fo' : $BCC ? '-o' : '-o ';
> + return !do_system("$Config{cc} -c $Config{ccflags} -I$corelib
> $cc_out$module_o $module.c");
> +}
> +
> +sub do_link {
> + my $module = shift;
> + my $module_lib = "$module.$Config{dlext}";
> + my $module_def = '';
> +
> + my $objs = "$module$Config{obj_ext}";
> + my $libs = $Config{libs};
> + my $lddlflags = $Config{lddlflags};
> + my $ld_out = '-o ';
> +
> + if ( $Is_MSWin32 ) {
> + require ExtUtils::Mksymlists;
> + ExtUtils::Mksymlists::Mksymlists(
> + 'NAME' => $module, 'DLBASE' => $module, 'IMPORTS' => {} );
> +
> + if ( $MSVC ) { # Microsoft
> + $ld_out = '-out:';
> + $libs .= " $Config{libperl}";
> + $module_def = "-def:$module.def";
> + } elsif ( $BCC ) { # Borland
> + $objs = "c0d32.obj $objs"; # Borland's startup obj; must
> be before others
> + $ld_out = '';
> + $module_lib = ",$module_lib";
> + $libs = ",,$Config{libperl} $libs";
> + $module_def = ",$module.def";
> + } elsif ( $MinGW ) { # MinGW GCC
> + (my $libperl = $Config{libperl}) =~ s/^(?:lib)?([^.]+).*$/$1/;
> + $libs = "-l$libperl $libs";
> + do_system("dlltool --def $module.def --output-exp $module.exp");
> + do_system("$Config{ld} $lddlflags -Wl,--base-file
> -Wl,$module.base $objs $ld_out$module_lib $libs $module.exp");
> + do_system("dlltool --def $module.def --output-exp $module.exp
> --base-file $module.base");
> + $module_def = "$module.exp";
> + }
> + }
> +
> + return !do_system("$Config{shrpenv} $Config{ld} $lddlflags $objs
> $ld_out$module_lib $libs $module_def");
> +}
> +
> sub do_system {
> my $cmd = shift;
> print "$cmd\n";
>
-Ken
|
|
From: Brian I. <in...@tt...> - 2003-02-16 19:35:44
|
On 15/02/03 21:43 -0600, Ken Williams wrote:
>
> On Thursday, February 13, 2003, at 03:30 AM, sc...@po... wrote:
> > Tonite at Portland.pm I gave a lightning talk entitled "MakeMaker Is
> > DOOMED!
> > or MakeMaker Is Dead! Long Live Module::Build!".
>
> Excellent. =) I should bring a Grim Reaper mask to YAPC/TPC this year.
I went to the talk. It got me to thinking about CPAN::MakeMaker and its
relationship to Module::Build.
Given:
The goal of CP::MM is to allow authors to write very simple/clean
Makefile.PLs that can potentially "turn on" very powerful features
like "bundling" with the flick of a switch.
The Makefile.PL produces a Makefile.
Then:
There is no reason why CP::MM can't produce a Makefile that wraps
Module::Build!
If the author has a version of Module::Build on there system that
is sufficient to handle the options that the author has requested
of CPAN::MakeMaker, then CP::MM will (optionally??) bundle M::B
into the author's dist. After that nobody is the wiser. Everything
just works.
Except that if the USER is installing on a makeless system, CP::MM
will prompt them to use Build instead.
Conclusions:
CP::MM becomes a migration tool for moving over to Module::Build.
The users always have the correct version of M::B, because it is
bundled in. (Just like CP::MM itself)
CP::MM focuses on "refactoring fancy functionality into simple
switches".
M::B focuses on replacing MakeMaker.
Yay! Thoughts?
Cheers, Brian
|
|
From: <sc...@po...> - 2003-02-16 19:31:23
|
On Sun, Feb 16, 2003 at 01:19:07PM -0600, Ken Williams wrote: > > MakeMaker 6.06 added a DESTDIR macro, inspired by the GNU make standard > > targets (http://www.gnu.org/manual/make/html_node/make_127.html). This > > allows a package builder to build a package normally, but install it > > into a different directory root for packaging. > > So 'destdir' is the/a standard name for this? Its what GNU make uses, and its what the Redhat and cpan2rpm folks suggested. |
|
From: Ken W. <ke...@ma...> - 2003-02-16 19:19:02
|
On Sunday, February 16, 2003, at 12:51 PM, sc...@po... wrote: > When building a package, one should build the software with the paths > from which it will ultimately run, not where it will initially be > installed. > So doing the above might cause some problems down the road. Yeah, good point. > MakeMaker 6.06 added a DESTDIR macro, inspired by the GNU make standard > targets (http://www.gnu.org/manual/make/html_node/make_127.html). This > allows a package builder to build a package normally, but install it > into a different directory root for packaging. So 'destdir' is the/a standard name for this? > Internally, install_map would do something like: > > sub install_map { > my ($self, $blib) = @_; > my $lib = File::Spec->catfile($blib,'lib'); > my $arch = File::Spec->catfile($blib,'arch'); > my $inst_lib = $self->{config}{sitelib}; > my $inst_arch = $self->{config}{sitearch}; > my $destdir = $self->{properties}{destdir} || ''; > > if( length $destdir ) { > $inst_lib = File::Spec->catfile($destdir, $inst_lib); > $inst_arch = File::Spec->catfile($destdir, $inst_arch); > } > > return {$lib => $inst_lib, > $arch => $inst_arch, > read => ''}; # To keep ExtUtils::Install quiet > } Looks good to me. I'll apply it. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-02-16 19:03:12
|
> From: "James Freeman" <jfr...@ta...> > Date: Sun Feb 16, 2003 11:59:39 AM US/Central > To: <ke...@ma...> > Subject: Module::Build Win32 patches > Reply-To: <jfr...@ta...> > > Hi Ken > > Module::Build is not very Win32 friendly. Actually Module::Build itself is very Win32 friendly, it takes pains to do things in a cross-platform way everywhere. Module::Build::Compat, a compatibility layer that builds a pass-through Makefile is clearly *not* very cross-platform yet, so your patches should help get the ball rolling in that area. However, your patch creates new problems: by using the full path name to the Makefile and Build scripts in the Makefile, the shell-quoting can-of-worms is now open. Consider what will happen if the full path is: '/home/ken/ foo/Makefile' or '/System Folder/foo/Makefile' or any number of more malicious variations. The second path above will render an OS X system quite useless when "rm -rf $makefile" is run. I'm not sure whether the right way to do this is to figure out shell quoting in a cross-platform way (*not* looking forward to this job), or to get relative paths working in a cross-platform way (would be much safer). What's your feeling on the matter? > I have patched the sources of all > the Modules to use more portable code. Mainly this is not using > ./Build as > the shell command but rather perl /path/to/Build as set by file spec. > Fixed > bareword error Cwd::cwd as well which was causing errors. Why would that cause errors? Is there some version of Cwd.pm that doesn't have cwd()? > Now a little less broken but failure to write a .packlist makes > uninstallation difficult. Right, a .packlist isn't written. Uninstallation is broken anyway, there should be a better mechanism designed rather than perpetuating the broken one. It's a goal of the project. > Another bug is that even though I incremented the $VERSION nmake > install > fails to recognise this and do a reinstall. Here are the highlights of > where > it is currently. I have attached a tar.gz of the patched distribution > for > you to run diff over. It would be helpful to submit patches against the current CVS tree, if you have access to a CVS client and a version of diff. Some of the Win32 errors in your output are fixed there already, actually. At least the "Can't unlink file lib/XSTest.c" one. Thanks again for the patches. -Ken |
|
From: <sc...@po...> - 2003-02-16 18:51:44
|
On Sun, Feb 16, 2003 at 11:34:48AM -0600, Ken Williams wrote: > Last week I did some poking around in the PREFIX-like areas of > Module::Build and discovered that some parts of it are totally broken, > and have been for several version releases. Ick. This really needs to > be addressed. And it needs to be simpler than it is in MakeMaker, for > sure. > > One way to make installation happen in another directory is like this: > > perl Build.PL config='sitelib=/tmp sitearch=/tmp/debian' > > Obviously not ideal, but it should work for the time being. When building a package, one should build the software with the paths from which it will ultimately run, not where it will initially be installed. So doing the above might cause some problems down the road. MakeMaker 6.06 added a DESTDIR macro, inspired by the GNU make standard targets (http://www.gnu.org/manual/make/html_node/make_127.html). This allows a package builder to build a package normally, but install it into a different directory root for packaging. Translated to Module::Build, it might look something like this: perl Build.PL ./Build ./Build test ./Build install --destdir=/tmp/debian-pkg-root Which would be added as $self->{properties}{destdir}. Internally, install_map would do something like: sub install_map { my ($self, $blib) = @_; my $lib = File::Spec->catfile($blib,'lib'); my $arch = File::Spec->catfile($blib,'arch'); my $inst_lib = $self->{config}{sitelib}; my $inst_arch = $self->{config}{sitearch}; my $destdir = $self->{properties}{destdir} || ''; if( length $destdir ) { $inst_lib = File::Spec->catfile($destdir, $inst_lib); $inst_arch = File::Spec->catfile($destdir, $inst_arch); } return {$lib => $inst_lib, $arch => $inst_arch, read => ''}; # To keep ExtUtils::Install quiet } Its simple for both Module::Build and the packager, and its the Correct way to handle packaging modules. |
|
From: Ken W. <ke...@ma...> - 2003-02-16 18:11:10
|
From: "James Freeman" <jfr...@ta...>
Date: Sun Feb 16, 2003 11:59:39 AM US/Central
To: <ke...@ma...>
Subject: Module::Build Win32 patches
Reply-To: <jfr...@ta...>
Hi Ken
Module::Build is not very Win32 friendly. I have patched the sources of
all
the Modules to use more portable code. Mainly this is not using ./Build
as
the shell command but rather perl /path/to/Build as set by file spec.
Fixed
bareword error Cwd::cwd as well which was causing errors. Now a little
less
broken but failure to write a .packlist makes uninstallation difficult.
Another bug is that even though I incremented the $VERSION nmake install
fails to recognise this and do a reinstall. Here are the highlights of
where
it is currently. I have attached a tar.gz of the patched distribution
for
you to run diff over.
cheers
Dr James Freeman
C:\tmp\Module-Build-0.15>perl Makefile.PL
C:\Perl\bin\Perl.exe Build.PL
Checking whether your kit is complete...
Looks good
Creating new 'Build' script for 'Module-Build' version '0.16'
C:\tmp\Module-Build-0.15>type Makefile
# PREREQ_PM => { Test=>q[0], ExtUtils::Install=>q[0], Config=>q[0],
File::Ba
sename=>q[0], File::Spec=>q[0], Cwd=>q[0], Data::Dumper=>q[0],
File::Compare=>q[
0], File::Find=>q[0], File::Copy=>q[0], File::Path=>q[0],
ExtUtils::Install=>q[0
.3], ExtUtils::ParseXS=>q[0], Archive::Tar=>q[0.22], YAML=>q[0.35] }
all :
perl C:\tmp\Module-Build-0.15\Build
realclean :
perl C:\tmp\Module-Build-0.15\Build realclean
del C:\tmp\Module-Build-0.15\Makefile /q /f
test :
perl C:\tmp\Module-Build-0.15\Build test
.DEFAULT :
perl C:\tmp\Module-Build-0.15\Build $@
.PHONY : install manifest
C:\tmp\Module-Build-0.15>nmake
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
perl C:\tmp\Module-Build-0.15\Build
lib/Module/Build.pm -> blib\lib/Module/Build.pm
lib/Module/Build/Base.pm -> blib\lib/Module/Build/Base.pm
lib/Module/Build/Compat.pm -> blib\lib/Module/Build/Compat.pm
lib/Module/Build/Platform/Amiga.pm ->
blib\lib/Module/Build/Platform/Amiga.pm
lib/Module/Build/Platform/darwin.pm ->
blib\lib/Module/Build/Platform/darwin.pm
lib/Module/Build/Platform/Default.pm ->
blib\lib/Module/Build/Platform/Default.p
m
lib/Module/Build/Platform/EBCDIC.pm ->
blib\lib/Module/Build/Platform/EBCDIC.pm
lib/Module/Build/Platform/MacOS.pm ->
blib\lib/Module/Build/Platform/MacOS.pm
lib/Module/Build/Platform/MPEiX.pm ->
blib\lib/Module/Build/Platform/MPEiX.pm
lib/Module/Build/Platform/RiscOS.pm ->
blib\lib/Module/Build/Platform/RiscOS.pm
lib/Module/Build/Platform/Unix.pm ->
blib\lib/Module/Build/Platform/Unix.pm
lib/Module/Build/Platform/VMS.pm ->
blib\lib/Module/Build/Platform/VMS.pm
lib/Module/Build/Platform/VOS.pm ->
blib\lib/Module/Build/Platform/VOS.pm
lib/Module/Build/Platform/Windows.pm ->
blib\lib/Module/Build/Platform/Windows.p
m
C:\tmp\Module-Build-0.15>nmake test
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
perl C:\tmp\Module-Build-0.15\Build test
t/basic.........ok
t/runthrough....ok
t/xs............ok 3/7'cl' is not recognized as an internal or external
command,
operable program or batch file.
t/xs............NOK 4'cl' is not recognized as an internal or external
command,
operable program or batch file.
t/xs............NOK 5Can't unlink file lib/XSTest.c: Permission denied
at
blib\l
ib/Module/Build/Base.pm line 935
t/xs............FAILED tests 4-6
Failed 3/7 tests, 57.14% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
----
---
t/xs.t 7 3 42.86% 4-6
Failed 1/3 test scripts, 66.67% okay. 3/30 subtests failed, 90.00% okay.
NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' : return code
'0xff'
Stop.
C:\tmp\Module-Build-0.15>nmake install
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
'install' is up-to-date
C:\tmp\Module-Build-0.15>perl Build install
Useless use of a variable in void context at
C:/Perl/lib/ExtUtils/Install.pm
lin
e 266.
Installing C:\Perl\site\lib\Module\Build.pm
Skipping C:\Perl\site\lib\Module\Build\Base.pm (unchanged)
Installing C:\Perl\site\lib\Module\Build\Compat.pm
Skipping C:\Perl\site\lib\Module\Build\Platform\Amiga.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\darwin.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\Default.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\EBCDIC.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\MacOS.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\MPEiX.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\RiscOS.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\Unix.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\VMS.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\VOS.pm (unchanged)
Skipping C:\Perl\site\lib\Module\Build\Platform\Windows.pm (unchanged)
C:\tmp\Module-Build-0.15>nmake realclean
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
perl C:\tmp\Module-Build-0.15\Build realclean
Deleting blib
Deleting _build
Deleting Build
del C:\tmp\Module-Build-0.15\Makefile /q /f
C:\tmp\Module-Build-0.15>
|
|
From: Ken W. <ke...@ma...> - 2003-02-16 17:34:41
|
On Saturday, February 15, 2003, at 03:23 PM, Chip Salzenberg wrote: > Hi there. I'm trying to make a Debian package of Module::Build. > The problem is, I can't figure out how to make "./Build install" > do the equivalent of the old "make install PREFIX=/tmp" ... I need > to install it in a tmp directory to create the package. Help? Hi Chip, It's great that you're putting this together. Last week I did some poking around in the PREFIX-like areas of Module::Build and discovered that some parts of it are totally broken, and have been for several version releases. Ick. This really needs to be addressed. And it needs to be simpler than it is in MakeMaker, for sure. One way to make installation happen in another directory is like this: perl Build.PL config='sitelib=/tmp sitearch=/tmp/debian' Obviously not ideal, but it should work for the time being. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-02-16 03:43:05
|
On Thursday, February 13, 2003, at 03:30 AM, sc...@po... wrote: > Tonite at Portland.pm I gave a lightning talk entitled "MakeMaker Is > DOOMED! > or MakeMaker Is Dead! Long Live Module::Build!". Excellent. =) I should bring a Grim Reaper mask to YAPC/TPC this year. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-02-16 03:41:15
|
On Thursday, February 13, 2003, at 12:25 AM, Andreas J. Koenig wrote: > Let's imagine, Module::Build could write an *equivalent* Makefile.PL. > One that could then be used with ExtUtils::MakeMaker (and without > Module::Build). If that were possible (even just for 80% of the > modules out there), that would convince many developers to switch, as > they would just distribute both Build.PL and Makefile.PL (no > duplicated work). Yeah, that's not a half-bad idea. The rub, of course, is that many options to Module::Build->new() might not translate very easily to MakeMaker options. But we could at least take a stab at it and see what happens. Of course, a tool that translates the *other* direction would be really nice too, for getting existing CPAN modules into the M::B world if the user so desires. This would likely involve a lot of voodoo, like perhaps hijacking WriteMakefile() and looking at the options given to the function, and perhaps scanning the Makefile.PL to see whether there's extra stuff in there that might be doing something significant. One good reason to do the EU::MM -> M::B step is that even if the M::B versions of things never made it to CPAN, we could generate META.yml files for those things that we're able to convert, and then generate some kind of dependency mapping for CPAN. -Ken |
|
From: Dave R. <au...@ur...> - 2003-02-13 18:52:59
|
On Thu, 13 Feb 2003, Andreas J. Koenig wrote: > Please send me your patch to CPAN.pm that supports Build.PL. I cannot > promise that I can work on it (tuits, tuits!), but I'll at least > consider doing it. It's after my sig. It's against 1.59_54 but it may just apply cleanly against the latest, for all I know. I'm pretty sure it works ;) One thing it could do better is prereq handling. Right now it just reads in _build/prereq and parses it, but it should really load Module::Build and ask it about the prereqs instead. This is what CPANPLUS currently does. > Let's imagine, Module::Build could write an *equivalent* Makefile.PL. > One that could then be used with ExtUtils::MakeMaker (and without > Module::Build). If that were possible (even just for 80% of the > modules out there), that would convince many developers to switch, as > they would just distribute both Build.PL and Makefile.PL (no > duplicated work). The result would not bother anybody among the user > community, as they would not even notice that Module::Build had been > working. For the 20% of complicated modules, Module::Build could just > die() with a few FIXME messages and that might be an incentive to many > a developer to actually produce patches. Maybe I'm missing something, > and surely this has been discussed before, but if you could discuss > this idea, I'd be interested to hear your arguments. I'm not sure I understand what you're suggesting. Are you saying that "./Build dist" could write out a Makefile.PL script? That's not a bad idea, I suppose. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Dave R. <au...@ur...> - 2003-02-13 18:49:01
|
On Thu, 13 Feb 2003, Andreas J. Koenig wrote: > Please send me your patch to CPAN.pm that supports Build.PL. I cannot > promise that I can work on it (tuits, tuits!), but I'll at least > consider doing it. Doh, I forgot the patch. Also, I wanted to point out that it is smart enough to try to install Module::Build if it sees a Build.PL file in the distro. /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ Only in .: cpan-patch diff -ur ../CPAN-1.59_54-old/lib/CPAN.pm ./lib/CPAN.pm --- ../CPAN-1.59_54-old/lib/CPAN.pm 2001-11-18 11:48:02.000000000 -0600 +++ ./lib/CPAN.pm 2001-11-18 13:00:26.000000000 -0600 @@ -3852,17 +3852,40 @@ my($mpl) = MM->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(), @@ -3873,7 +3896,7 @@ $self->{'configure'} = $configure; } elsif (-f MM->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"; @@ -3886,9 +3909,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; @@ -3899,7 +3922,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; @@ -3907,9 +3930,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; } @@ -4370,7 +4398,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" }; @@ -4407,16 +4435,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.}; # It's probably worth to record the reason, so let's retry # local $/; # my $fh = IO::File->new("$system |"); # STDERR? STDIN? @@ -4430,7 +4459,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"; @@ -4532,6 +4565,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 @@ -4560,6 +4594,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; @@ -4606,7 +4650,12 @@ return; } - 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"); $self->{make_test} = "YES"; @@ -4637,7 +4686,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"); @@ -4712,8 +4766,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) = ""; |
7 messages has been excluded from this view by a project administrator.
