module-build-general — General discussion about Module::Build project

Re: [Module::Build] missing CBuilder

[Randy W. S. <ml...@th...>]

Marvin Humphrey wrote:
> Greets,
> 
> It looks like in some cases my XS distro KinoSearch may not be able to 
> installed via CPAN without extra intervention since the release of 
> Module::Build 0.28.  The problem seems to arise when Module::Build has 
> not been installed, and the passthrough Makefile.PL gets called.  After 
> you reply yes at the prompt asking if you want to install Module::Build, 
> it installs without ExtUtils::CBuilder, even on systems where 
> ExtUtils::CBuilder can be installed later via the CPAN shell without a 
> problem.
> 
> Is the answer to add ExtUtils::CBuilder to the build_requires hash?

Hmm, Module::Build itself doesn't require EU::CBuilder, so it is only a 
recommended prereq. BUT, modules that use M::B may have an indirect & 
implicit dependency on EU::CBuilder. I.E. They depend on an optional 
feature of M::B. This dependency is never explicitly mentioned anywhere 
so installs can fail.

Currently the only solution is to make the dependency explicit in your 
module's build files by listing EU::CBuilder in 'build_requires' as you 
already observed.

I wonder if there should be a better way to express this dependency. 
Maybe it could be declared like this:

use Module::Build features => qw( C_support );

Instead of having indirect prereqs listed in build files where it really 
has nothing directly to do with the distro. Module::Build could then do 
whatever magic is needed under the hood to add the appropriate prereqs.

Randy.

[Module::Build] missing CBuilder

[Marvin H. <ma...@re...>]

Greets,

It looks like in some cases my XS distro KinoSearch may not be able  
to installed via CPAN without extra intervention since the release of  
Module::Build 0.28.  The problem seems to arise when Module::Build  
has not been installed, and the passthrough Makefile.PL gets called.   
After you reply yes at the prompt asking if you want to install  
Module::Build, it installs without ExtUtils::CBuilder, even on  
systems where ExtUtils::CBuilder can be installed later via the CPAN  
shell without a problem.

Is the answer to add ExtUtils::CBuilder to the build_requires hash?

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/

Re: [Module::Build] dynamic creation?

[Gene B. <gb...@si...>]

Ha! Excellent!  #1 is the answer for me and for MT. :)  Thank you,
Randy.

-Gene

On Sun, 2006-05-21 at 19:46 -0400, Randy W. Sims wrote:

> 1) specify it explicitly in your Build.PL file:
> 
> my $build = Module::Build->new(
>      module_name => 'Foo::Bar',
> 
>      dist_abstract => 'A module to Foo::Bar',    # ADDED
>      dist_version  => '0.00_01',                 # ADDED
>      dist_author   => 'you <yo...@so...>', # ADDED
> 
>      license => 'perl',
>      PL_files => {
>          'lib/Foo/Bar.pm.PL' => 'lib/Foo/Bar.pm',
>      },
> );

Re: [Module::Build] What I've been up to

[Ron S. <ro...@sa...>]

On Sun, 21 May 2006 19:24:12 -0400, Randy W. Sims wrote:

Hi Randy

> Wow, you've been busy while I was gone... Although, I don't recall
> seeing that item on the todo list. ;)

It wasn't on /Ken's/ TODO list because he outsourced the laborious part...
--
Ron Savage
ro...@sa...
http://savage.net.au/index.html

[Module::Build] Updated META.yml stats

[Randy W. S. <Ra...@Th...>]

<http://thepierianspring.org/perl/meta/>

1399 Distributions using Module::Build

28 using the new 0.28 branch in the short time since it was released.

Re: [Module::Build] dynamic creation?

[Randy W. S. <ml...@th...>]

Gene Boggs wrote:
> How do I generate the main, module_name package via the PL_files?  I
> have Module::Build 0.2801 and (as with previous versions) get this
> instead of a Build file:
> 
> ~/bin/Foo-Bar> perl Build.PL --foo=wtf
> Can't find file lib/Foo/Bar.pm to determine version
> at /usr/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm line 934.

By default M::B tries to find meta information about your distribution 
from the name of the distribution: abstract, author, version. The 
abstract and author come from parsing any POD in the "main" module file. 
The version is detected by primitive scanning with a regexp. So...

Given your distribution name of 'Foo-Bar', M::B is looking for a file 
'lib/Foo/Bar.pm' to detect the meta information. It doesn't find the 
file so it complains as above.

You have two options to help M::B find the meta information.

1) specify it explicitly in your Build.PL file:

my $build = Module::Build->new(
     module_name => 'Foo::Bar',

     dist_abstract => 'A module to Foo::Bar',    # ADDED
     dist_version  => '0.00_01',                 # ADDED
     dist_author   => 'you <yo...@so...>', # ADDED

     license => 'perl',
     PL_files => {
         'lib/Foo/Bar.pm.PL' => 'lib/Foo/Bar.pm',
     },
);

2) You can tell it in which file to find the meta information:

my $build = Module::Build->new(
     module_name => 'Foo::Bar',

     dist_version_from => 'lib/Foo/Bar.pm.PL', # ADDED

     license => 'perl',
     PL_files => {
         'lib/Foo/Bar.pm.PL' => 'lib/Foo/Bar.pm',
     },
);

Note, however, that (2) may cause other problems. In particular, when 
scanning your file for the version it will find the line:

our \$VERSION = '0.00_1';

which it will then try to evaluate to determine your version. This will 
fail because the line is not a line of perl code but a string which 
contains *escaped* perl code (I.E. the backslash).

In order to make it work, you will need to "trick" the primitive parser 
we use to get the version. Currently, that can be done by adding at the 
top of your file a valid declaration

package Foo::Bar;
our $VERSION = '0.00_01;

Option (1) is the safest and best approach. I can't guarantee that the 
workaround for (2) will always work.

Regards,
Randy.

Re: [Module::Build] What I've been up to

[Randy W. S. <ml...@th...>]

Ken Williams wrote:
> Hi all,
> 
> By way of explanation for where I've been the past few days, I offer the 
> attached photograph.

Wow, you've been busy while I was gone... Although, I don't recall 
seeing that item on the todo list. ;)

Congratulations!

Randy.

[Module::Build] dynamic creation?

[Gene B. <gb...@si...>]

How do I generate the main, module_name package via the PL_files?  I
have Module::Build 0.2801 and (as with previous versions) get this
instead of a Build file:

~/bin/Foo-Bar> perl Build.PL --foo=wtf
Can't find file lib/Foo/Bar.pm to determine version
at /usr/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm line 934.

Here are the relevant, plain-Jane files I'm using:

### Build.PL file:

#!/usr/bin/perl
use strict;
use warnings;
use Module::Build;
my $build = Module::Build->new(
    module_name => 'Foo::Bar',
    license => 'perl',
    PL_files => {
        'lib/Foo/Bar.pm.PL' => 'lib/Foo/Bar.pm',
    },
);
$build->create_build_script();

### Bar.pm.PL file:

#!/usr/bin/perl
use strict;
use warnings;
use My::Module::Build;
my $build = My::Module::Build->current();
my $foo = $build->args( 'foo' );
use IO::File;
my $fh = IO::File->new( '> '. shift );
print $fh <<PACKAGE;
package Foo::Bar;
our \$VERSION = '0.00_1';
use strict;
use warnings;
sub foo { return $foo }
1;
PACKAGE
close $fh;


I have tried subclassing, in order to create the main module before its
version is checked, by adding ACTION_code() to a copy of
Module::Build::Base->new() like so:

package My::Module::Build;
use base qw( Module::Build );
use strict;
use warnings;
sub new {
  my $self = shift()->_construct(@_);
  $self->{invoked_action} = $self->{action} ||= 'Build_PL';
  $self->cull_args(@ARGV);
  die "Too early to specify a build action '$self->{action}'.  Do 'Build
$self->{action}' instead.\n"
    if $self->{action} && $self->{action} ne 'Build_PL';
  $self->dist_name;
  $self->ACTION_code;  # XXX Added to pre-create the main module.
  $self->dist_version;
  $self->check_manifest;
  $self->check_prereq;
  $self->check_autofeatures;
  $self->_set_install_paths;
  $self->_find_nested_builds;
  return $self;
}


This works just fine (although you get "No build_params?
at /usr/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm line 995."
warnings) -unless- you try to use My::Module::Build->current() and get
at the $build object in the generating Bar.pm.PL file.  If so, you get
the familiar, "Can't find file lib/Foo/Bar.pm to determine version"
fatal error.

Hints?  Help?

Thank you,
Gene Boggs

[Module::Build] ANNOUNCE: Module-Build 0.2801 -> CPAN

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

Hi,

Last night I uploaded Module::Build 0.2801, the first maintenance  
release in the 0.28 series, fixing a few bugs.  Below are the changes  
since 0.28.

  -Ken


0.2801  Sun May 21 00:07:40 CDT 2006

  - Module::Build::Compat's emulation of INC is incorrectly prepending
    a -I to the value of INC. This is incorrect because there should
    already be a -I on the value. I.E. it's "perl Makefile.PL INC=-Ifoo"
    not "perl Makefile.PL INC=foo" so Compat should not prefix a -I.
    [Michael Schwern]

  - Native batch scripts under Windows should not be converted by
    pl2bat. [Spotted by Ron Savage]

  - Tweaked the way we determine whether a file is executable on Unix.
    We use this determination to decide whether to make it executable
    during installation. [Julian Mehnle]

  - Replaced a vestigial 'next' with 'return' now that the code is in a
    subroutine (htmlify_pods()), not a loop. [Ron Savage]

  - Fixed a guaranteed failure in t/signature.t when TEST_SIGNATURE was
    set. [Eric R. Meyers]

  - Fixed a test failure that occurred when testing or installing in
    unattended mode - the code to test whether unattended mode and
    attended mode are working properly was assuming that we started out
    in attended mode. [Steve Peters]

  - Improved our stand-in YAML generator that we use to generate
    META.yaml when authors don't have a copy of YAML.pm installed on
    their machine.  It was unable to handle things like embedded
    newlines in the data, now it has a much more extensive escaping
    mechanism. [Stephen Adkins]

  - Revised the docs for --prefix and PREFIX. [Michael Schwern]

Re: [Module::Build] win32 install problem

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

On May 19, 2006, at 2:28 AM, demerphq wrote:

> I supplied a patch to Archive::Tar which fixed it. Unfortunately the
> patch was rejected. At this point I think it was rejected for no
> reason, and I intend to follow up on the subject today.
>
> http://rt.cpan.org/Ticket/Display.html?id=18720#txn-186661
> http://rt.cpan.org/Ticket/Display.html?id=18720#txn-191947
>
> If it turns out that the basis of the rejection was incorrect I intend
> to give Jos a second chance to fix things himself. If he doesnt I
> intend to do something drastic, possibly going so far as to fork
> Archive::Tar.
>
> Anyway, use of a later Archive::Tar guarantees that the tar file you
> produce will not work with much of the free decompression software
> available on Win32.


Eek.

Well, god speed, man.  I hope you can get things worked out, but I  
agree that this would be worth a fork & namechange if not.  The whole  
point of the module is essentially broken now.

  -Ken

Re: [Module::Build] win32 install problem

[Ben L. <bla...@gm...>]

> > As it turns out, though, installing it manually via copying from
> > the tar.gz (ugh), as you suggest, did the trick just fine.  M::B
>
> No, I did not suggest that. I suggested you could install it in the official
> manner, so to speak, from Randy's site, or download it and install it like any
> other module.
>
> I certainly like to see /exactly/ what was happening when it did not install gor
> you.

With ppm version 2.1.6, I would attempt to install A::T.  It was a
very old version, and ppm would find an upgrade.  Upon a verify
--upgrade for AT, I'd get that the package was already up to date.
Some web searching told me that many people have had similar problems
with ppm version 2 (it seems version 3 is not so troublesome), as
version 2 doesn't much like to upgrade packages it is using, and
reporting that a package is already up to date is ppm2's backwards way
of saying 'I can't do that'.  There wasn't an accepted solution out
there for dealing with it via ppm 2, I found cases 4 pages into google
results of people who had to upgrade their AS installation entirely to
get around the problem for an important module which required c
compliation (details having since taken their leave of me).

Installing AT from the tgz or via the CPAN module got me nowhere.
Perl actually crashes halfway through the tests, suggesting I let
Microsoft know about this problem.  Along with this came an
all-too-telling message, after reading previous messages on this
thread, that long filename extraction support would be disabled.

Whenever I removed AT manually, ppm wouldn't start, plain and simple.
Putting it back fixed the problem.  You said:
o Install local copy of V 1.29 'manually' (via a program actually)
which gave me the idea to just throw the .pm files in the correct
location, which I did.  I'm not sure what you did here, but after
this, your ppm would run again.  Mine ran again too, after I installed
it manually, but even a forced verify upgrade gives me a reassuring
message that AT is up to date, just as before, so I don't really see
how to duplicate your behavior.

Ben

Ben

Re: [Module::Build] win32 install problem

[demerphq <dem...@gm...>]

On 5/19/06, Ron Savage <ro...@sa...> wrote:
> On Fri, 19 May 2006 09:28:58 +0200, demerphq wrote:
>
> Hi
>
> > software available on Win32. Jos decided to change the long file
> > format handling sometime after he took of maint of Archive::Tar to
> > POSIX style. This style is not well supported and has restrictive
>
> It'd be great if the output files didn't trigger the WinZip problem mentioned
> here:
>
> http://savage.net.au/Perl-modules/html/installing-a-module.html
>
> oh so long ago :-(.

That is exactly the problem my patch attempts to resolve.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: [Module::Build] win32 install problem

[Ron S. <ro...@sa...>]

On Fri, 19 May 2006 03:02:03 +0200, Ben Lavender wrote:

Hi Ben

> As it turns out, though, installing it manually via copying from
> the tar.gz (ugh), as you suggest, did the trick just fine.  M::B

No, I did not suggest that. I suggested you could install it in the official=
 
manner, so to speak, from Randy's site, or download it and install it like=
 any 
other module.

I certainly like to see /exactly/ what was happening when it did not install=
 gor 
you.
-- 
Cheers
Ron Savage, ro...@sa... on 19/05/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Module::Build] win32 install problem

[Ron S. <ro...@sa...>]

On Fri, 19 May 2006 09:28:58 +0200, demerphq wrote:

Hi

> software available on Win32. Jos decided to change the long file
> format handling sometime after he took of maint of Archive::Tar to
> POSIX style. This style is not well supported and has restrictive

It'd be great if the output files didn't trigger the WinZip problem=
 mentioned 
here:

http://savage.net.au/Perl-modules/html/installing-a-module.html

oh so long ago :-(.

-- 
Cheers
Ron Savage, ro...@sa... on 19/05/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Module::Build] win32 install problem

[demerphq <dem...@gm...>]

On 5/18/06, Ken Williams <ke...@ma...> wrote:
> Unfortunately, on some platforms *no* version of A::T seems to work
> properly (as far as I'm last aware - I may have fallen behind on the
> issue), and its maintainers haven't been receptive to patches that
> fix it.  Also, on some platforms (Unix, cygwin, etc.) we'll pretty
> much always have /usr/bin/tar around, so we don't really need *any*
> version of A::T.

I supplied a patch to Archive::Tar which fixed it. Unfortunately the
patch was rejected. At this point I think it was rejected for no
reason, and I intend to follow up on the subject today.

http://rt.cpan.org/Ticket/Display.html?id=18720#txn-186661
http://rt.cpan.org/Ticket/Display.html?id=18720#txn-191947

If it turns out that the basis of the rejection was incorrect I intend
to give Jos a second chance to fix things himself. If he doesnt I
intend to do something drastic, possibly going so far as to fork
Archive::Tar.

Anyway, use of a later Archive::Tar guarantees that the tar file you
produce will not work with much of the free decompression software
available on Win32. Jos decided to change the long file format
handling sometime after he took of maint of Archive::Tar to POSIX
style. This style is not well supported and has restrictive path
length and file name length constriants. The old mechism used the Gnu
Extended Header mechanism which has no upper limit on file or path
length, and appears to be supported by most tar packages, certainly it
is supported by GNU tar which should be widely available.

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: [Module::Build] win32 install problem

[Ben L. <bla...@gm...>]

> I don't know what you tried. Here's what I just did, using ppm V 2.1.6 & Perl V
> 5.8.7 from Randy Kobes at uwinnipeg:
>

I tried two things:  Installing archive::tar manually, which died
somehow with nmake; this is not uncommon for attempting to install
packages on win32.

As A::T wanted to use nmake, which often means a package wants to do
something funky with its install, I didn't want to install it
manually.  ppm at version 2 doesn't much like to upgrade packages it
uses, and when I renamed it as a test, ppm wouldn't start, as your
example shows.  A bit more funging didn't help any.

As it turns out, though, installing it manually via copying from the
tar.gz (ugh), as you suggest, did the trick just fine.  M::B built,
tested, installed and worked, and all was well on my little
overly-paranoid development platform.  This was using the patch
supplied by Ken W. a few days ago.

I'm continually astounded by the help I find on mailing lists for perl
modules.  Thanks to everyone for the extra help on this.

Ben

Re: [Module::Build] win32 install problem

[Ron S. <ro...@sa...>]

On Thu, 18 May 2006 19:12:24 +0200, Ben Lavender wrote:

Hi Ben

> After banging my head at this all day, I'm stuck on it.  ppm won't
> upgrade Archive::Tar, and I can't make it install itself by any
> means (nmake strikes again!).  It seems I'm either stuck upgrading

I don't know what you tried. Here's what I just did, using ppm V 2.1.6 &=
 Perl V 
5.8.7 from Randy Kobes at uwinnipeg:

o Manually delete Archive::Tar

o C:\Backup>ppm install --location=3Dhttp://theoryx5.uwinnipeg.ca/ppms 
Archive::Tar
Can't locate Archive/Tar.pm in @INC (@INC contains: C:/Perl/lib=
 C:/Perl/site/lib 
.) at C:/Perl/site/
lib/PPM.pm line 28.
BEGIN failed--compilation aborted at C:/Perl/site/lib/PPM.pm line 28.
Compilation failed in require at C:\Perl\bin/ppm.bat line 21.
BEGIN failed--compilation aborted at C:\Perl\bin/ppm.bat line 21.

o Install local copy of V 1.29 'manually' (via a program actually)

o C:\Backup>ppm install --location=3Dhttp://theoryx5.uwinnipeg.ca/ppms 
Archive::Tar
Version 0.072 of 'Archive-Tar' is already installed.
Remove it, or use 'verify --upgrade Archive-Tar'.
(This is because it's mentioned in C:\Perl\site\lib\ppm.xml)

C:\Backup>ppm verify --upgrade --location=3Dhttp://theoryx5.uwinnipeg.ca/ppms=
 
Archive::Tar
Duplicate POD found (shadowing?): Win32 (C:\Perl\lib/Win32.pod)
    Already seen in C:\Perl\lib/Win32.pm
[Chop many more of same. How to I suppress this 'duplicate' stuff :-(?]
Bytes transferred: 37769
Installing C:\Perl\html\site\lib\Archive\Tar.html
Installing C:\Perl\html\site\lib\Archive\Tar\File.html
Installing C:\Perl\site\lib\Archive\Tar.pm
Installing C:\Perl\site\lib\Archive\Tar\Constant.pm
Installing C:\Perl\site\lib\Archive\Tar\File.pm
Installing C:\Perl\bin\ptardiff.bat
Installing C:\Perl\bin\ptar.bat
Installing C:\Perl\bin\ptardiff
Installing C:\Perl\bin\ptar
Writing C:\Perl\site\lib\auto\Archive\Tar\.packlist
Duplicate POD found (shadowing?): Win32 (C:\Perl\lib/Win32.pod)
    Already seen in C:\Perl\lib/Win32.pm
[Chop may more of same]
Package 'Archive-Tar' is up to date.
-- 
Cheers
Ron Savage, ro...@sa... on 19/05/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Module::Build] win32 install problem

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

On May 16, 2006, at 11:12 PM, Randy W. Sims wrote:

> Ben Lavender wrote:
>> The supplied patch gets me to perl Build test, which fails at this  
>> point:
>> t\runthrough......ok 13/28Use of uninitialized value in pattern  
>> match (m//) at c
>> :/work/Perl/lib/File/Spec/Win32.pm line 72.
>> Use of uninitialized value in pattern match (m//) at c:/work/Perl/ 
>> lib/File/Spec/
>> Win32.pm line 72.
>> Use of uninitialized value in pattern match (m//) at c:/work/Perl/ 
>> lib/File/Spec/
>> Win32.pm line 140.
>> t\runthrough......ok 19/28
>> t\runthrough......NOK 20#   Failed test in t\runthrough.t at line  
>> 151.
>> #          got: 'Can't locate object method "create_archive" via  
>> package "Archiv
>> e::Tar" (perhaps you forgot to load "Archive::Tar"?) at C:\work 
>> \mbtest\Module-Bu
>> ild-0.28\blib\lib/Module/Build/Base.pm line 3436.
>> # '
>> #     expected: ''
>> t\runthrough......ok 28/28# Looks like you failed 1 test of 28.
>
> The patch works because it throws away the volume part, but the  
> volume shouldn't be there at all.

Yeah, it shouldn't, but there it is. =)  Older versions of File::Spec  
include it, and even though it's not strictly incorrect to have a  
drive letter on a relative path, if we don't jump through the  
byzantine File::Spec hoops correctly we'll screw things up.

Newer versions of File::Spec don't include the drive letter in this  
situation - there are some regression tests in File::Spec now to  
ensure that.

  -Ken

Re: [Module::Build] win32 install problem

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

On May 16, 2006, at 11:12 PM, Randy W. Sims wrote:

> Ben Lavender wrote:
>> Archive::Tar isn't there because it's version .23 instead of 1.08 as
>> recommended/required.  I tried installing that, but I managed to get
>> an entirely new and unrelated error, unrelated to this problem or  
>> this
>> mailing list (not my week!).  I made sure to include those pattern
>> match errors because they get spewn out like carrots from a salad
>> shooter throughout all steps of the install and test process.  It's
>> midnight for me and I'll try and bend Archive::Tar to my will  
>> tomorrow
>> and I'll make another run then.
>> For the record, I get this message while installing:
>> * Archive::Tar (0.23) is installed, but we prefer to have 1.08
>> I'm all for the softening of computer language to make it more user
>> friendly, but required is required and prefer is prefer :)
>
> Not sure why the test in t/runthrough.t didn't detect the missing  
> prereq...
>
>   SKIP: {
>     skip( "not sure if we can create a tarball on this platform", 1 )
>       unless $mb->check_installed_status('Archive::Tar', 0) ||
> 	     $mb->isa('Module::Build::Platform::Unix');
>     ...
>   }

I think basically everything is working as designed - the reason we  
"prefer" to have a newer version of Archive::Tar is that older  
versions fail on some platforms, but we don't exactly know which  
ones.  In this case, we tell the user what version we have, what  
version we think we *want* to have, and then we test things out to  
see if it works.

That said, this probably isn't designed very well. =)  For one thing,  
many users never care about the ability to create tarballs, because  
they only want to use M::B to install things, not to create  
distributions.  For another thing, it would be nice if we could just  
identify the version of A::T we require, then list it as a dependency.

Unfortunately, on some platforms *no* version of A::T seems to work  
properly (as far as I'm last aware - I may have fallen behind on the  
issue), and its maintainers haven't been receptive to patches that  
fix it.  Also, on some platforms (Unix, cygwin, etc.) we'll pretty  
much always have /usr/bin/tar around, so we don't really need *any*  
version of A::T.

More than you wanted to know, I'm sure....

  -Ken

Re: [Module::Build] win32 install problem

[Ben L. <bla...@gm...>]

> >
> > For the record, I get this message while installing:
> > * Archive::Tar (0.23) is installed, but we prefer to have 1.08
> > I'm all for the softening of computer language to make it more user
> > friendly, but required is required and prefer is prefer :)
>
> Not sure why the test in t/runthrough.t didn't detect the missing prereq...
>
>    SKIP: {
>      skip( "not sure if we can create a tarball on this platform", 1 )
>        unless $mb->check_installed_status('Archive::Tar', 0) ||
>              $mb->isa('Module::Build::Platform::Unix');
>      ...
>    }
>
> Unfortunately, I wont be able to look into this more until the weekend.
> I'll be out of town from tomorrow morning until Friday evening.
>
> Randy.
>

After banging my head at this all day, I'm stuck on it.  ppm won't
upgrade Archive::Tar, and I can't make it install itself by any means
(nmake strikes again!).  It seems I'm either stuck upgrading core bits
piecemeal or doing without.  As mid-project is not the time for a
platform upgrade, I'm going to do without for now and install the
newest version of activestate in a few months, which includes a ppm
that can upgrade modules it uses itself and a newer version of
archive::tar to begin with.

I appreciate all the help on this, and I'll still run patches or
whatever if you guys want any more test cases, but I'm moving forward.
 What I'm trying to say is:  don't waste your 2 days of freedom on it
:)

cheers,
ben

Re: [Module::Build] Can someone please give sourceforge a swift kick

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

On May 16, 2006, at 9:06 PM, David Wheeler wrote:

> On May 16, 2006, at 18:37, Ken Williams wrote:
>
>> Anyone know how to get the list of subscribers from sourceforge,  
>> so we could move to a perl.org-hosted list?  I suppose we could  
>> screen-scrape it from the mailman interface...
>
> I think that's what I did when I migrated the Bricolage mail lists.  
> It only took a few minutes, really.

Yeah, you're right, that was easy.  Copy++, paste++.

I'll contact the perl.org guys to see about switching the list over,  
and I'll send a get-ready-for-the-switch announcement when it looks  
imminent.

  -Ken

Re: [Module::Build] What I've been up to

[Ron S. <ro...@sa...>]

On Wed, 17 May 2006 09:21:32 -0500, Ken Williams wrote:

Hi Ken

> By way of explanation for where I've been the past few days, I
> offer the attached photograph.

Gee - It's not often a man admits being pregnant...
-- 
Cheers
Ron Savage, ro...@sa... on 18/05/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Module::Build] What I've been up to

[Tyler M. <ty...@yi...>]

Ken Williams <ke...@ma...> wrote:
> We are extremely proud to announce the birth of our new son, Lewis  
> Robert Williams.  He was born on Mother's Day, Sunday May 14th, at  
> 1:58 pm. 

	Congratulations!!! Our daughter was born on my birthday, July the
18th.. and my wife was both on boxing day, December 26th... It looks like
our kids are going to have to get us presents on or about the same day we
give presents to them.. hardly seems fair, does it? ;-)

	Cheers,
		Tyler

Re: [Module::Build] What I've been up to

[David W. <da...@ki...>]

On May 17, 2006, at 07:21, Ken Williams wrote:

> By way of explanation for where I've been the past few days, I  
> offer the attached photograph.

Hey, congrats, Ken! Born 366 days after our daughter. Great time of  
year! :-)

Good luck!

David

[Module::Build] What I've been up to

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

Hi all,

By way of explanation for where I've been the past few days, I offer  
the attached photograph.