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

Re: [Module::Build] broken META.yml file

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

Eric Wilhelm wrote:
> # from Randy W. Sims
> # on Tuesday 16 May 2006 12:58 pm:
> 
>>> 1.
>>> M::B::PP [$f, $b]
>>> P::P [$f, $b]
>>>
>>> 2.
>>> M::B::PP [$f, $b]
>>> P::P ["$f $b"]
>>>
>>> 3.
>>> M::B::PP ["  $f", "  $b"]
>>> P::P ["  $f\n  $b"]
>>>
>>> The automated test is not trivial, but is still left as an exercise
>>> for the reader.
>> Maybe we should just complain and ask the user to specify the
>> 'dist_author' argument to the constructor if we detect multiple lines?
>> Or we could require format (2) above in the AUTHOR section where there
>> is one address perl line; we should be able to detect that reliably
>> enough.
> 
> Er, do you mean "format (1)" and "one address per paragraph"?
> 
> It's the only one that works consistently with the current code.  Plus, 
> (2) and (3) are both somewhat incorrect anyway (any pod renderer gets 
> to put the stuff from (2) on a single line and as for (3), pod2html 
> doesn't render links in literal paragraphs.)

Actually, I meant (3). When looking at the top part of you previous 
message, I mis-counted. However, your point about pod2html kills that. 
So, yeah, we could require (1), the only viable option, or we could 
display an informative message to the user if we detect an author 
section spanning multiple lines.

Randy.

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

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

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...

Will we also need to point gmane.org at the new list?

Randy.

Re: [Module::Build] win32 install problem

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

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. All paths at this point should be relative, 
which is why we could get away with a simple fileparse()

> 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');
     ...
   }

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.

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

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

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.

Best,

David

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

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

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...

  -Ken

On May 16, 2006, at 4:21 PM, Randy W. Sims wrote:

> After holding messages for ~ 3 days (which if I had seen, I could  
> have saved myself some time yesterday looking into issues that had  
> already been looked into), sourceforge now seems to be selectively  
> letting messages through. Some messages I sent haven't showed up  
> yet when I've sent other messages before and since that have gone  
> through. I've also received CC'd messages that haven't yet shown up  
> on the list....
>
> Until it's straightened out, please CC me directly on all  
> messages... assuming this goes through.
>
> Randy.
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

Re: [Module::Build] win32 install problem

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

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 "A=
rchiv
e::Tar" (perhaps you forgot to load "Archive::Tar"?) at C:\work\mbtest\Modu=
le-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.

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 :)

cheers, and thanks for all the help on this,
ben


On 5/16/06, Ken Williams <ke...@ma...> wrote:
>
> On May 16, 2006, at 7:40 AM, demerphq wrote:
>
> > Im pretty sure that the lines
> >
> >   my ($name, $path) =3D File::Basename::fileparse($pods->{$pod},
> >                                                 qr{\.(?:pm|plx?|pod)$})=
;
> >   my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path ) );
> >
> > are wrong. FS->splitdir() splits a directory specification NOT a path.
> > If you use splitdir on a path that includes a volume specification
> > then obviously it wont work out (actually it will return the volume as
> > tho it was a directory)
> >
> > I think you need something like:
> >
> >  my $spec=3DFile::Spec->canonpath( $pods->{$pod} );
> >  my ($vol,$path,$file)=3D File::Spec->splitpath($spec);
> >  my ($name) =3D File::Basename::fileparse($file,qr{\.(?:pm|plx?|pod)$})=
;
> >  my @dirs =3D File::Spec->splitdir( $path );
> >  pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
>
> Okay, does this patch rectify the situation?
>
>   -Ken
>
> =3D=3D=3D lib/Module/Build/Base.pm
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- lib/Module/Build/Base.pm    (revision 1905)
> +++ lib/Module/Build/Base.pm    (local)
> @@ -2523,7 +2523,8 @@
>       my ($name, $path) =3D File::Basename::fileparse($pods->{$pod},
>                                                   qr{\.(?:pm|plx?|pod)$})=
;
> -    my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path ) );
> +    my ($vol, $dirs) =3D File::Spec->splitpath($path, 1);
> +    my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $dirs ) );
>       pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
>       my $fulldir =3D File::Spec->catfile($htmldir, @rootdirs, @dirs);
>
>

Re: [Module::Build] broken META.yml file

[Eric W. <scr...@gm...>]

# from Randy W. Sims
# on Tuesday 16 May 2006 12:58 pm:

>> 1.
>> M::B::PP [$f, $b]
>> P::P [$f, $b]
>>
>> 2.
>> M::B::PP [$f, $b]
>> P::P ["$f $b"]
>>
>> 3.
>> M::B::PP [" =A0$f", " =A0$b"]
>> P::P [" =A0$f\n =A0$b"]
>>
>> The automated test is not trivial, but is still left as an exercise
>> for the reader.
>
>Maybe we should just complain and ask the user to specify the
>'dist_author' argument to the constructor if we detect multiple lines?
>Or we could require format (2) above in the AUTHOR section where there
>is one address perl line; we should be able to detect that reliably
> enough.

Er, do you mean "format (1)" and "one address per paragraph"?

It's the only one that works consistently with the current code.  Plus,=20
(2) and (3) are both somewhat incorrect anyway (any pod renderer gets=20
to put the stuff from (2) on a single line and as for (3), pod2html=20
doesn't render links in literal paragraphs.)

=2D-Eric
=2D-=20
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
=2D-Donald Knuth
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [Module::Build] Capturing test output to please CPANPLUS

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

[Resending...]

Ken Williams wrote:
> 
> On Apr 10, 2006, at 1:46 AM, Randy W. Sims wrote:
> 
>> Randy W. Sims wrote:
>>
>>> Will something like this work for a temporary solution that we can  
>>> maybe figure out how to extend in the future to always capture  output?
>>
>>
>> Regarding Ticket #9793 [1]
>>
>> Scratch that. I don't really like my previous solution. I'm not  sure 
>> Module::Build needs to be responsible for capturing output; I  can't 
>> really see any benifit. Is there a reason CPANPLUS (or  
>> CPANPLUS::Dist::Build) can't do this, like below (borrowing again  
>> from Jos' patch), or are there other issues I'm not aware of?
> 
> 
> Probably as much as possible should go in CPP:D:Build, unless there  are 
> aspects of it that would also be nice to have in the core, and  they 
> wouldn't generate too much clutter.
> 
> In general I'm leery of messing with filehandles too much in the  core, 
> because the people can't do their own messing if they want to.

I've been sitting on the attached patch against CPANPLUS::Dist::Build
for a while because 1) I'm not knowledgeable about CPANPLUS to know how
to properly test it; and 2) it still has the problem of suspending
output until the test completes before sending to stdout.

I thought maybe I could extend the patch a little further to use IO::Tee
to eliminate the delayed output, but it doesn't seem to work:

#!/usr/bin/perl

use File::Spec;
chdir( File::Spec->catdir( glob('~'), 'Module-Build' ) );

use Module::Build;
my $mb = Module::Build->new_from_context;
$mb->dispatch('build');


require IO::String;
my $io = IO::String->new;

require IO::Tee;
my $tee = IO::Tee->new(\*STDOUT, $io);


my $SAVE_OUT = select($tee);

$mb->dispatch('test', test_files => 't/runthrough.t', verbose => 1);

select($SAVE_OUT);


my $result = ${$io->string_ref};
# craft a report from $result . $@

__END__


This works fine when tests succeed, but when there is a failure in the
test...

# Looks like you failed 1 test of 33.
dubious
          Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
          Failed 1/33 tests, 96.97% okay (less 4 skipped tests: 28 okay,
84.85%)
Undefined format "Symbol::GEN128" called at
/usr/share/perl/5.8/Test/Harness.pm line 542.


Anyone know how to make this work, please?

Randy.

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

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

After holding messages for ~ 3 days (which if I had seen, I could have 
saved myself some time yesterday looking into issues that had already 
been looked into), sourceforge now seems to be selectively letting 
messages through. Some messages I sent haven't showed up yet when I've 
sent other messages before and since that have gone through. I've also 
received CC'd messages that haven't yet shown up on the list....

Until it's straightened out, please CC me directly on all messages... 
assuming this goes through.

Randy.

Re: [Module::Build] win32 install problem

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

Ken Williams wrote:
> 
> On May 16, 2006, at 7:40 AM, demerphq wrote:
> 
>> Im pretty sure that the lines
>>
>>   my ($name, $path) = File::Basename::fileparse($pods->{$pod},
>>                           qr{\.(?:pm|plx?|pod)$});
>>   my @dirs = File::Spec->splitdir( File::Spec->canonpath( $path ) );
>>
>> are wrong. FS->splitdir() splits a directory specification NOT a path.
>> If you use splitdir on a path that includes a volume specification
>> then obviously it wont work out (actually it will return the volume as
>> tho it was a directory)
>>
>> I think you need something like:
>>
>>  my $spec=File::Spec->canonpath( $pods->{$pod} );
>>  my ($vol,$path,$file)= File::Spec->splitpath($spec);
>>  my ($name) = File::Basename::fileparse($file,qr{\.(?:pm|plx?|pod)$});
>>  my @dirs = File::Spec->splitdir( $path );
>>  pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
> 
> Okay, does this patch rectify the situation?

I can now reproduce this using AS perl 5.6 on Windows. The failure is in 
->_find_pods at the call to abs2rel()

   $files{$file} = File::Spec->abs2rel($file, $dir)
     if $self->contains_pod( $file )

Here are some values as they are passed in and their results:

file => blib\lib
dir  => blib\lib
   result => C:

file => blib\lib/Simple.pm
dir  => blib\lib
   result => C:Simple.pm

file => blib\lib/Simple
dir  => blib\lib
   result => C:Simple

file => blib\lib/Simple/AllPod.pod
dir  => blib\lib
   result => C:Simple\AllPod.pod

file => blib\lib/Simple/NoPod.pm
dir  => blib\lib
   result => C:Simple\NoPod.pm

file => blib\arch
dir  => blib\arch
   result => C:

file => blib\lib
dir  => blib\lib
   result => C:

This is a bug in the version of File::Spec supplied, I think.

It still fails in the same way if I convert the paths to absolute paths 
before the above call to abs2rel.

   $file = File::Spec->rel2abs($file);
   $dir  = File::Spec->rel2abs($dir);
   $files{$file} = File::Spec->abs2rel($file, $dir)
     if $self->contains_pod( $file )

With:

file => C:\Downloads\Module-Build-0.28\t\_tmp\Simple\blib\lib\Simple.pm
dir  => C:\Downloads\Module-Build-0.28\t\_tmp\Simple\blib\lib
   result => C:Simple.pm

Is there a workaround or do we require an update File::Spec ???

Randy.

Re: [Module::Build] win32 install problem

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

On May 16, 2006, at 7:40 AM, demerphq wrote:

> Im pretty sure that the lines
>
>   my ($name, $path) = File::Basename::fileparse($pods->{$pod},
> 						  qr{\.(?:pm|plx?|pod)$});
>   my @dirs = File::Spec->splitdir( File::Spec->canonpath( $path ) );
>
> are wrong. FS->splitdir() splits a directory specification NOT a path.
> If you use splitdir on a path that includes a volume specification
> then obviously it wont work out (actually it will return the volume as
> tho it was a directory)
>
> I think you need something like:
>
>  my $spec=File::Spec->canonpath( $pods->{$pod} );
>  my ($vol,$path,$file)= File::Spec->splitpath($spec);
>  my ($name) = File::Basename::fileparse($file,qr{\.(?:pm|plx?|pod)$});
>  my @dirs = File::Spec->splitdir( $path );
>  pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;

Okay, does this patch rectify the situation?

  -Ken

=== lib/Module/Build/Base.pm
==================================================================
--- lib/Module/Build/Base.pm	(revision 1905)
+++ lib/Module/Build/Base.pm	(local)
@@ -2523,7 +2523,8 @@
      my ($name, $path) = File::Basename::fileparse($pods->{$pod},
						  qr{\.(?:pm|plx?|pod)$});
-    my @dirs = File::Spec->splitdir( File::Spec->canonpath( $path ) );
+    my ($vol, $dirs) = File::Spec->splitpath($path, 1);
+    my @dirs = File::Spec->splitdir( File::Spec->canonpath( $dirs ) );
      pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
      my $fulldir = File::Spec->catfile($htmldir, @rootdirs, @dirs);

Re: [Module::Build] broken META.yml file

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

Eric Wilhelm wrote:
> # from Stephen Adkins
> # on Tuesday 16 May 2006 05:55 am:
> 
> 
>>1. The Gantry distribution does "author" wrong
> 
> 
>>I don't know if somewhere else in Module::Build needs to do something
>>different in scanning Gantry.pm (to get the desired arrayref), but
>>Module::Build::YAML is behaving correctly (and creating the same
>>result as YAML.pm).
> 
> 
> =head1 AUTHOR
> 
> Foo <fo...@ba...>
> 
> Bar <ba...@ba...>
> 
> =cut
> 
> ...is two paragraphs (renders on separate lines in perldoc)
> 
> =head1 AUTHOR
> 
> Foo <fo...@ba...>
> Bar <ba...@ba...>
> 
> =cut
> 
> ...is one paragraph
> 
> =head1 AUTHOR
> 
>   Foo <fo...@ba...>
>   Bar <ba...@ba...>
> 
> =cut
> 
> ...is one literal paragraph of two lines
> 
> =head1 AUTHOR
> 
>   Foo <foo at bar dot com>
> 
> =cut
> 
> ... is ignored without my patch, which was ignored.

Not ignored; just not applied. ;)  I saw the discussion, but kept quiet 
because I have a stong bias against obfuscation: I stubbornly refuse to 
give ground to spammers-I was here first. Besides, obfuscated addresses 
are as easy to detect and de-obfuscate as a normal address, and there 
are several ways to obfuscate email where your patch only detects one 
particular method.

> But it looks like the behavior WRT lines/paragraphs/literals may depend 
> on whether Pod::Parser is installed as textblock() is fed a paragraph 
> while the M::B::PodParser::_myparse_from_filehandle() is going 
> line-by-line.
> 
> From the looks of things, the first three cases should turn into 
> something like this (where $f = "Foo ..." and $b = "Bar ...".)
> 
> 1.
> M::B::PP [$f, $b]
> P::P [$f, $b]
> 
> 2.
> M::B::PP [$f, $b]
> P::P ["$f $b"]
> 
> 3.
> M::B::PP ["  $f", "  $b"]
> P::P ["  $f\n  $b"]
> 
> The automated test is not trivial, but is still left as an exercise for 
> the reader.

Maybe we should just complain and ask the user to specify the 
'dist_author' argument to the constructor if we detect multiple lines? 
Or we could require format (2) above in the AUTHOR section where there 
is one address perl line; we should be able to detect that reliably enough.

Randy.

Re: [Module::Build] broken META.yml file

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

Stephen Adkins wrote:
> Hi,
> 
> I am happy to address any real issue that you've found.
> It appears you are reporting two issues.
> Please clarify if I am misunderstanding the issues you reported.
> 
> 1. The Gantry distribution does "author" wrong
> 
> I think I am doing this right.  The fact that the two authors show
> up as one string is not a YAML or Module::Build::YAML problem.
> The "author" element is extracted from the "=head1 AUTHOR"
> section of "Gantry.pm" because "module_name => 'Gantry',"
> is in Build.PL (and no "author" entry exists).

Oops, sorry. I didn't look deep enough. Your are correct.

> 2. It would be nicer if long text sections were formatted nicer
> 
> I think the requirement that Module::Build::YAML is meeting is to
> produce valid YAML which works.
> 
> Module::Build::YAML - Provides just enough YAML support so that
> Module::Build works even if YAML.pm is not installed
> 
> I wanted to stay away from the many flavors of multi-line formatting
> which are available in the full YAML spec.  However, I believe that
> Module::Build::YAML does work properly.

Yes, this does work. I didn't know if it was worth the trouble of adding 
the additional behavior. I'm very happy with what you've already 
provided though.

Thanks,
Randy.

Re: [Module::Build] broken META.yml file

[Eric W. <scr...@gm...>]

# from Stephen Adkins
# on Tuesday 16 May 2006 05:55 am:

>1. The Gantry distribution does "author" wrong

>I don't know if somewhere else in Module::Build needs to do something
>different in scanning Gantry.pm (to get the desired arrayref), but
>Module::Build::YAML is behaving correctly (and creating the same
>result as YAML.pm).

=3Dhead1 AUTHOR

=46oo <fo...@ba...>

Bar <ba...@ba...>

=3Dcut

=2E..is two paragraphs (renders on separate lines in perldoc)

=3Dhead1 AUTHOR

=46oo <fo...@ba...>
Bar <ba...@ba...>

=3Dcut

=2E..is one paragraph

=3Dhead1 AUTHOR

  Foo <fo...@ba...>
  Bar <ba...@ba...>

=3Dcut

=2E..is one literal paragraph of two lines

=3Dhead1 AUTHOR

  Foo <foo at bar dot com>

=3Dcut

=2E.. is ignored without my patch, which was ignored.

But it looks like the behavior WRT lines/paragraphs/literals may depend=20
on whether Pod::Parser is installed as textblock() is fed a paragraph=20
while the M::B::PodParser::_myparse_from_filehandle() is going=20
line-by-line.

=46rom the looks of things, the first three cases should turn into=20
something like this (where $f =3D "Foo ..." and $b =3D "Bar ...".)

1.
M::B::PP [$f, $b]
P::P [$f, $b]

2.
M::B::PP [$f, $b]
P::P ["$f $b"]

3.
M::B::PP ["  $f", "  $b"]
P::P ["  $f\n  $b"]

The automated test is not trivial, but is still left as an exercise for=20
the reader.

=2D-Eric
=2D-=20
Minus 1 million points for not setting your clock forward and trying the
code.
=2D-Michael Schwern
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [Module::Build] win32 install problem

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

On 5/16/06, Ben Lavender <bla...@gm...> wrote:
> On 5/16/06, Randy W. Sims <ml...@th...> wrote:
> > Sorry to take so long to look at this. I haven't yet been able to
> > reproduce the problem. The problem seems to be that a directory name is
> > getting corrupted somewhere. Eg. In this line from above:
> >
> >   mkdir blib\binhtml\bin\C:.:
> >     Invalid argument at lib/Module/Build/Base.pm line 25
> >
> > The trailing 'C:.' does not belong there.
> >
> > It'd be useful to see what values are in $path and @dirs if you are abl=
e
> > to apply the following patch:
> >
> > --- Base.pm.orig        2006-04-28 00:14:03.000000000 -0400
> > +++ Base.pm     2006-05-15 20:37:05.796875000 -0400
> > @@ -2519,6 +2519,9 @@
> >       my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path )=
 );
> >       pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;

...

> > It'd also be useful to know if this happens in a directory without
> > spaces, and if it happens after upgrading File::Spec[1]
>
> The patch provides the same result, in directories both with and without =
spaces:
>
> $name =3D 'config_data';
> $path =3D 'C:.\\';
> $dirs =3D [
>           'C:.'
>         ];
>
> A directory without spaces gives the same result.
>
> As before, upgrading File::Spec is something I might try and live
> without.  I'd need to investigate what other multitude of packages I'm
> using might be affected by that upgrade; I'll try and do some of that
> today.

Im pretty sure that the lines

   my ($name, $path) =3D File::Basename::fileparse($pods->{$pod},
=09=09=09=09=09=09  qr{\.(?:pm|plx?|pod)$});
   my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path ) );

are wrong. FS->splitdir() splits a directory specification NOT a path.
If you use splitdir on a path that includes a volume specification
then obviously it wont work out (actually it will return the volume as
tho it was a directory)

I think you need something like:

  my $spec=3DFile::Spec->canonpath( $pods->{$pod} );
  my ($vol,$path,$file)=3D File::Spec->splitpath($spec);
  my ($name) =3D File::Basename::fileparse($file,qr{\.(?:pm|plx?|pod)$});
  my @dirs =3D File::Spec->splitdir( $path );
  pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;

Cheers,
Yves

--=20
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] win32 install problem

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

On 5/12/06, Ken Williams <ke...@ma...> wrote:
> Hi Ben,
>
> That looks to me like a File::Spec problem.  Could you tell us what
> version of File::Spec you currently have installed?  We may need to
> change the version we depend on for Win32 users.

Its not a version problem.

D:\home\.cpan5.8.x\build\PathTools-3.18>perl -MDDS -MFile::Spec
-e"Dump [File::Spec->splitdir('C:.\\')]"
$ARRAY1 =3D [
            'C:.',
            ''
          ];

 Its documented behaviour:

splitdir
  The opposite of "catdir()".

      @dirs =3D File::Spec->splitdir( $directories );

  $directories must be only the directory portion of the path on systems
  that have the concept of a volume or that have path syntax that
  differentiates files from directories.


--=20
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] broken META.yml file

[Stephen A. <spa...@gm...>]

Hi,

I am happy to address any real issue that you've found.
It appears you are reporting two issues.
Please clarify if I am misunderstanding the issues you reported.

1. The Gantry distribution does "author" wrong

I think I am doing this right.  The fact that the two authors show
up as one string is not a YAML or Module::Build::YAML problem.
The "author" element is extracted from the "=3Dhead1 AUTHOR"
section of "Gantry.pm" because "module_name =3D> 'Gantry',"
is in Build.PL (and no "author" entry exists).

Here are the relevant files.

http://search.cpan.org/src/PHILCROW/Gantry-3.30/META.yml
http://search.cpan.org/src/PHILCROW/Gantry-3.30/Build.PL
http://search.cpan.org/src/PHILCROW/Gantry-3.30/lib/Gantry.pm

The META.yml which comes with the Gantry-3.30 distribution
was generated with Module::Build version 0.2611, without YAML.pm,
and it creates illegal YAML (as you pointed out). So does the
initial 0.28 which uses Module::Build::YAML.

--- #YAML:1.0
name: Gantry
version: 3.30
author:
  - Tim Keefer <tk...@gm...>
Phil Crow <phi...@ya...>
abstract: Web application framework for mod_perl, cgi, etc.
license: perl
generated_by: Module::Build version 0.2611, without YAML.pm

On my system, I have YAML.pm installed, and a "./Build distmeta"
creates:

author:
  - |-
    Tim Keefer <tk...@gm...>
    Phil Crow <phi...@ya...>

This is legal YAML (good) but still not the array that is desired (bad).
It is also a bit nicer to look at than the output of Module::Build::YAML,
but it is functionally equivalent (below).

author:
  - "Tim Keefer <tk...@gm...>\nPhil Crow <phi...@ya...>"

I don't know if somewhere else in Module::Build needs to do something
different in scanning Gantry.pm (to get the desired arrayref), but
Module::Build::YAML is behaving correctly (and creating the same
result as YAML.pm).

2. It would be nicer if long text sections were formatted nicer

I think the requirement that Module::Build::YAML is meeting is to
produce valid YAML which works.

Module::Build::YAML - Provides just enough YAML support so that
Module::Build works even if YAML.pm is not installed

I wanted to stay away from the many flavors of multi-line formatting
which are available in the full YAML spec.  However, I believe that
Module::Build::YAML does work properly.

Instead of

text: |-
   YAML::Node is a class for generating and manipulating these
     containers. A YAML node (or ynode) is a tied hash, array or
     scalar. In most ways it behaves just like the plain thing. But you
     can assign and retrieve and YAML type tag URI to it. For the hash
     flavor, you can also assign the order that the keys will be
     retrieved in. By default a ynode will offer its keys in the same
     order that they were assigned.

it produces

text: "YAML::Node is a class for generating and manipulating
these\ncontainers. A YAML node (or ynode) is a tied hash, array
or\nscalar. In most ways it behaves just like the plain thing. But
you\ncan assign and retrieve and YAML type tag URI to it. For the
hash\nflavor, you can also assign the order that the keys will
be\nretrieved in. By default a ynode will offer its keys in the
same\norder that they were assigned."

in a single line.  This is uglier, but it is still functionally correct.
If people think I need to implement the more aesthetically pleasing
format, I will consider adding it.

(I was considering implementing the Load() subroutine with the promise
that Module::Build::YAML::Load() can read anything it can Dump().
I wanted to stay away from the fancy multi-line YAML formats to
make parsing simpler.)

Stephen

On 5/15/06, Randy W. Sims <ml...@th...> wrote:
> Stephen Adkins wrote:
> > Hi,
> >
> > I wrote Module::Build::YAML.
> > I offer these patches.
> >
> > Both of the previously mentioned broken YAML files were a
> > result of embedded newlines.  I opted to tackle newlines and
> > all of the other special characters which I could find which
> > YAML considers special.
> >
> > I think this version will be quite an improvement in terms of
> > robustness in the presence of "odd" characters in the scalar
> > values.  I patched
>
> I'm not sure this is correct; although, it is much improved. The second
> instance with the module 'Gantry' should have an 'author' node that is
> an array containing 2 elements. With your patch, I untared Gantry and ran
>
> # ysh
> ysh > <META.yml
> YAML Error: Invalid element in map
>     Code: YAML_LOAD_ERR_BAD_MAP_ELEMENT
>     Line: 6
>     Document: 1
>   at C:\devel\perl\5.8.7\site\lib/YAML.pm line 60
> ysh > :q
>
> Which is the original error. After running
>
> # Build.PL
> [ignore output]
>
> # perl Build distmeta
> Deleting Makefile.PL
> Creating Makefile.PL
> Deleting META.yml
> Creating META.yml
>
> # ysh
> ysh > <META.yml
> $VAR1 =3D {
>    'name' =3D> 'Gantry',
>    'version' =3D> '3.30',
>    'author' =3D> [
>      'Tim Keefer <tk...@gm...>
> Phil Crow <phi...@ya...>'
>    ],
>    ...
> };
>
> Notice that author is an array with *one* element that is a multiline
> string.
>
> In the other case, we probably have a problem up stream(???): I would
> expect the abstract to be returned as a single string removing the
> formatting from the pod. I.E. Single \n should be collapsed along with
> surrounding whitespace, while \n\n should remain a paragraph break.
>
> But do notice that YAML.pm when give a string with embedded \n
> characters writes the result out as verbatim text:
>
> use YAML;
> require YAML::Node;
>
> my $data =3D { text =3D>
>    "YAML::Node is a class for generating and manipulating these
>    containers. A YAML node (or ynode) is a tied hash, array or
>    scalar. In most ways it behaves just like the plain thing. But you
>    can assign and retrieve and YAML type tag URI to it. For the hash
>    flavor, you can also assign the order that the keys will be
>    retrieved in. By default a ynode will offer its keys in the same
>    order that they were assigned."
> };
>
> my $node =3D YAML::Node->new($data);
> print Dump $node;
>
> __END__
>
> outputs:
> ---
> text: |-
>    YAML::Node is a class for generating and manipulating these
>      containers. A YAML node (or ynode) is a tied hash, array or
>      scalar. In most ways it behaves just like the plain thing. But you
>      can assign and retrieve and YAML type tag URI to it. For the hash
>      flavor, you can also assign the order that the keys will be
>      retrieved in. By default a ynode will offer its keys in the same
>      order that they were assigned.
>
>
> Whereas the same text without embedded \n gets printed as:
> ---
> text: 'YAML::Node is a class for generating and manipulating these
> containers. A YAML node (or ynode) is a tied hash, array or scalar. In
> most ways it behaves just like the plain thing. But you can assign and
> retrieve and YAML type tag URI to it. For the hash flavor, you can also
> assign the order that the keys will be retrieved in. By default a ynode
> will offer its keys in the same order that they were assigned.'
>
> Regards,
> Randy.
>

Re: [Module::Build] win32 install problem

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

On 5/16/06, Randy W. Sims <ml...@th...> wrote:
> Ben Lavender wrote:
> > Hi all,
> >
> > Module::Build won't install for me and I can't find anyone else on the
> > net with my problem.
> >
> > My setup is XP SP 2.
> > ------perl -v:
> >
> > This is perl, v5.6.1 built for MSWin32-x86-multi-thread
> > (with 1 registered patch, see perl -V for more detail)
> >
> > Copyright 1987-2001, Larry Wall
> >
> > Binary build 635 based on sources provided by
> >  ActiveState Corp. http://www.ActiveState.com
> > Built 21:04:21 Feb 25 2003
> >
> > -----Error (perl Build.PL works fine):
> > C:\Documents and Settings\Administrator\Desktop\firebird
> > incoming\Module-Build-0
> > .28.tar\Module-Build-0.28>Build
> > 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 72.
> > Use of uninitialized value in pattern match (m//) at
> > c:/work/Perl/lib/File/Spec/
> > Win32.pm line 140.
> > mkdir blib\binhtml\bin\C:.: Invalid argument at lib/Module/Build/Base.p=
m
> > line 25
> > 29
> >
> > Any assistance would be appreciated!  Please let me know if more
> > information is required.
>
> Sorry to take so long to look at this. I haven't yet been able to
> reproduce the problem. The problem seems to be that a directory name is
> getting corrupted somewhere. Eg. In this line from above:
>
>   mkdir blib\binhtml\bin\C:.:
>     Invalid argument at lib/Module/Build/Base.pm line 25
>
> The trailing 'C:.' does not belong there.
>
> It'd be useful to see what values are in $path and @dirs if you are able
> to apply the following patch:
>
> --- Base.pm.orig        2006-04-28 00:14:03.000000000 -0400
> +++ Base.pm     2006-05-15 20:37:05.796875000 -0400
> @@ -2519,6 +2519,9 @@
>       my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path ) )=
;
>       pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
>
> +use Data::Dumper; warn Data::Dumper->Dump( [$name, $path, \@dirs],
> +                                           [qw(name path dirs)] );
> +
>       my $fulldir =3D File::Spec->catfile($htmldir, @rootdirs, @dirs);
>       my $outfile =3D File::Spec->catfile($fulldir, "${name}.html");
>       my $infile  =3D File::Spec->abs2rel($pod);
>
>
> It'd also be useful to know if this happens in a directory without
> spaces, and if it happens after upgrading File::Spec[1]

The patch provides the same result, in directories both with and without sp=
aces:

$name =3D 'config_data';
$path =3D 'C:.\\';
$dirs =3D [
          'C:.'
        ];

A directory without spaces gives the same result.

As before, upgrading File::Spec is something I might try and live
without.  I'd need to investigate what other multitude of packages I'm
using might be affected by that upgrade; I'll try and do some of that
today.

>
> Regards,
> Randy.
>
> 1. <http://search.cpan.org/dist/PathTools/>
>

Re: [Module::Build] Capturing test output to please CPANPLUS

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

Ken Williams wrote:
> 
> On Apr 10, 2006, at 1:46 AM, Randy W. Sims wrote:
> 
>> Randy W. Sims wrote:
>>
>>> Will something like this work for a temporary solution that we can  
>>> maybe figure out how to extend in the future to always capture  output?
>>
>>
>> Regarding Ticket #9793 [1]
>>
>> Scratch that. I don't really like my previous solution. I'm not  sure 
>> Module::Build needs to be responsible for capturing output; I  can't 
>> really see any benifit. Is there a reason CPANPLUS (or  
>> CPANPLUS::Dist::Build) can't do this, like below (borrowing again  
>> from Jos' patch), or are there other issues I'm not aware of?
> 
> 
> Probably as much as possible should go in CPP:D:Build, unless there  are 
> aspects of it that would also be nice to have in the core, and  they 
> wouldn't generate too much clutter.
> 
> In general I'm leery of messing with filehandles too much in the  core, 
> because the people can't do their own messing if they want to.

I've been sitting on the attached patch against CPANPLUS::Dist::Build 
for a while because 1) I'm not knowledgeable about CPANPLUS to know how 
to properly test it; and 2) it still has the problem of suspending 
output until the test completes before sending to stdout.

I thought maybe I could extend the patch a little further to use IO::Tee 
to eliminate the delayed output, but it doesn't seem to work:

#!/usr/bin/perl

use File::Spec;
chdir( File::Spec->catdir( glob('~'), 'Module-Build' ) );

use Module::Build;
my $mb = Module::Build->new_from_context;
$mb->dispatch('build');


require IO::String;
my $io = IO::String->new;

require IO::Tee;
my $tee = IO::Tee->new(\*STDOUT, $io);


my $SAVE_OUT = select($tee);

$mb->dispatch('test', test_files => 't/runthrough.t', verbose => 1);

select($SAVE_OUT);


my $result = ${$io->string_ref};
# craft a report from $result . $@

__END__


This works fine when tests succeed, but when there is a failure in the 
test...

# Looks like you failed 1 test of 33.
dubious
         Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
         Failed 1/33 tests, 96.97% okay (less 4 skipped tests: 28 okay, 
84.85%)
Undefined format "Symbol::GEN128" called at 
/usr/share/perl/5.8/Test/Harness.pm line 542.


Anyone know how to make this work, please?

Randy.

Re: [Module::Build] broken META.yml file

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

Stephen Adkins wrote:
> Hi,
> 
> I wrote Module::Build::YAML.
> I offer these patches.
> 
> Both of the previously mentioned broken YAML files were a
> result of embedded newlines.  I opted to tackle newlines and
> all of the other special characters which I could find which
> YAML considers special.
> 
> I think this version will be quite an improvement in terms of
> robustness in the presence of "odd" characters in the scalar
> values.  I patched

I'm not sure this is correct; although, it is much improved. The second 
instance with the module 'Gantry' should have an 'author' node that is 
an array containing 2 elements. With your patch, I untared Gantry and ran

# ysh
ysh > <META.yml
YAML Error: Invalid element in map
    Code: YAML_LOAD_ERR_BAD_MAP_ELEMENT
    Line: 6
    Document: 1
  at C:\devel\perl\5.8.7\site\lib/YAML.pm line 60
ysh > :q

Which is the original error. After running

# Build.PL
[ignore output]

# perl Build distmeta
Deleting Makefile.PL
Creating Makefile.PL
Deleting META.yml
Creating META.yml

# ysh
ysh > <META.yml
$VAR1 = {
   'name' => 'Gantry',
   'version' => '3.30',
   'author' => [
     'Tim Keefer <tk...@gm...>
Phil Crow <phi...@ya...>'
   ],
   ...
};

Notice that author is an array with *one* element that is a multiline 
string.

In the other case, we probably have a problem up stream(???): I would 
expect the abstract to be returned as a single string removing the 
formatting from the pod. I.E. Single \n should be collapsed along with 
surrounding whitespace, while \n\n should remain a paragraph break.

But do notice that YAML.pm when give a string with embedded \n 
characters writes the result out as verbatim text:

use YAML;
require YAML::Node;

my $data = { text =>
   "YAML::Node is a class for generating and manipulating these
   containers. A YAML node (or ynode) is a tied hash, array or
   scalar. In most ways it behaves just like the plain thing. But you
   can assign and retrieve and YAML type tag URI to it. For the hash
   flavor, you can also assign the order that the keys will be
   retrieved in. By default a ynode will offer its keys in the same
   order that they were assigned."
};

my $node = YAML::Node->new($data);
print Dump $node;

__END__

outputs:
---
text: |-
   YAML::Node is a class for generating and manipulating these
     containers. A YAML node (or ynode) is a tied hash, array or
     scalar. In most ways it behaves just like the plain thing. But you
     can assign and retrieve and YAML type tag URI to it. For the hash
     flavor, you can also assign the order that the keys will be
     retrieved in. By default a ynode will offer its keys in the same
     order that they were assigned.


Whereas the same text without embedded \n gets printed as:
---
text: 'YAML::Node is a class for generating and manipulating these 
containers. A YAML node (or ynode) is a tied hash, array or scalar. In 
most ways it behaves just like the plain thing. But you can assign and 
retrieve and YAML type tag URI to it. For the hash flavor, you can also 
assign the order that the keys will be retrieved in. By default a ynode 
will offer its keys in the same order that they were assigned.'

Regards,
Randy.

Re: [Module::Build] win32 install problem

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

Ben Lavender wrote:
> Hi all,
> 
> Module::Build won't install for me and I can't find anyone else on the
> net with my problem.
> 
> My setup is XP SP 2.
> ------perl -v:
> 
> This is perl, v5.6.1 built for MSWin32-x86-multi-thread
> (with 1 registered patch, see perl -V for more detail)
> 
> Copyright 1987-2001, Larry Wall
> 
> Binary build 635 based on sources provided by
>  ActiveState Corp. http://www.ActiveState.com
> Built 21:04:21 Feb 25 2003
> 
> -----Error (perl Build.PL works fine):
> C:\Documents and Settings\Administrator\Desktop\firebird 
> incoming\Module-Build-0
> .28.tar\Module-Build-0.28>Build
> 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 72.
> Use of uninitialized value in pattern match (m//) at 
> c:/work/Perl/lib/File/Spec/
> Win32.pm line 140.
> mkdir blib\binhtml\bin\C:.: Invalid argument at lib/Module/Build/Base.pm 
> line 25
> 29
> 
> Any assistance would be appreciated!  Please let me know if more
> information is required.

Sorry to take so long to look at this. I haven't yet been able to 
reproduce the problem. The problem seems to be that a directory name is 
getting corrupted somewhere. Eg. In this line from above:

  mkdir blib\binhtml\bin\C:.:
    Invalid argument at lib/Module/Build/Base.pm line 25

The trailing 'C:.' does not belong there.

It'd be useful to see what values are in $path and @dirs if you are able 
to apply the following patch:

--- Base.pm.orig        2006-04-28 00:14:03.000000000 -0400
+++ Base.pm     2006-05-15 20:37:05.796875000 -0400
@@ -2519,6 +2519,9 @@
      my @dirs = File::Spec->splitdir( File::Spec->canonpath( $path ) );
      pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;

+use Data::Dumper; warn Data::Dumper->Dump( [$name, $path, \@dirs],
+                                           [qw(name path dirs)] );
+
      my $fulldir = File::Spec->catfile($htmldir, @rootdirs, @dirs);
      my $outfile = File::Spec->catfile($fulldir, "${name}.html");
      my $infile  = File::Spec->abs2rel($pod);


It'd also be useful to know if this happens in a directory without 
spaces, and if it happens after upgrading File::Spec[1]

Regards,
Randy.

1. <http://search.cpan.org/dist/PathTools/>

[Module::Build] [perl #39098] Pod::Html error stops CPAN install/test of Pod::Readme

[Tels <nos...@bl...>]

Moin,

"Randy W. Sims" <ml...@th...> wrote:

>Rafael Garcia-Suarez wrote:
[snip]
>> I'd say the problem is with Module::Build, which should probably
>> proceed if pod2html can't build HTML docs. Anyway this is a M::B bug,
>> not a Pod::Html one. The original POD document is actually malformed.

[snip]
>I think we should also test for these types of failures for the author=20
>during 'disttest' or at some other point where the author can correct=20
>the problem before the user sees it. Any preference as to where to put=20
>such tests?

That is the reasoning behind having every distribution pod (pod exists and=
=20
is wellformed) and pod coverage tests (pod covers all public methods in=20
some form).

Not having them is a Kwalitee malus.

However, this is not "enforced", read every author is free to not test his=
=20
pod at all (or even include one). Including broken POD is an "oops" just=20
like not running "make disttest" (and thus forgetting a file in MANIFEST)=20
or any similiar mistakes every author makes regulary. I am not sure how=20
we can improve the situation except make it much much easier for authors=20
to write (and run) these tests.

I am thinking of a command line version of the kwalitee script, that=20
checks the rating, and gives tipps on how to improve it, or even auto=20
generated the t/podcheck.t and t/podcover.t files (among other things).

Unfortunately, the CPANTS project seems stuck atm :(

Best wishes,

Tels

=2D-=20
 Signed on Mon May 15 14:42:57 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Wo die Schoschonen sch=C3=B6n wohnen."

[Module::Build] Getting PREFIX to work

[Rob K. <rob...@gm...>]

All -

    PREFIX requires 0.28 to work. Most places have 0.2611 (or
something close) installed. How do I structure my Build.PL so that it
will force CPAN or CPANPLUS to install the latest Module::Build?

Thanks,
Rob

Re: [Module::Build] [PATCH] Failure to find local 'lib' dir during M::B install with tests that chdir

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

On May 12, 2006, at 5:13 PM, Eric Wilhelm wrote:

> # from Chris Dolan
> # on Friday 12 May 2006 12:31 pm:
>
>>  CP+ doesn't consider the case where it is
>> building Module::Build itself, and uses a pre-loaded M::B.  It seems
>> to me that CPANPLUS::Dist::Build should fall back to Makefile.PL mode
>>   (i.e. running external files) when it detects that its trying to
>> compile M::B itself.
>
> Should it have to detect that?  Could Build.PL handle that?


It's possible, I think, but I'm not sure.  I'd have to think about  
how that could work, e.g. how we'd detect we're running under  
CPANPLUS, how we'd circumvent what it's trying to do, etc.  It seems  
like the whole idea would be a little too sneaky.

It would also mean that people would have to install the new M::B  
once manually (because CP+ won't install it) before things would  
start working.

  -Ken

Re: [Module::Build] [PATCH] Failure to find local 'lib' dir during M::B install with tests that chdir

[Eric W. <scr...@gm...>]

# from Chris Dolan
# on Friday 12 May 2006 12:31 pm:

>=A0CP+ doesn't consider the case where it is =A0
>building Module::Build itself, and uses a pre-loaded M::B. =A0It seems =A0
>to me that CPANPLUS::Dist::Build should fall back to Makefile.PL mode
> =A0 (i.e. running external files) when it detects that its trying to
> compile M::B itself.

Should it have to detect that?  Could Build.PL handle that?

=2D-Eric
=2D-=20
"Everything goes wrong all at once."
=2D-Quantized Revision of Murphy's Law
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------