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

Re: [Module::Build] How to I specify in META.yml a package needs a C compiler?

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

On Mar 16, 2006, at 9:57 PM, R. Bernstein wrote:

> dlisp options from Kobe's CPAN search I think use META.yml and
> META.yml is set via Module::Build. I have a package that requires a C
> compiler, but dlisp/META.ymal doesn't show that. How do I specify that
> (e.g. in Build.PL)?

There's currently no field in META.yml that indicates whether a C  
compiler is needed.  It's a pretty good idea, though.  In any case,  
the DLSP options must be coming from somewhere else.

  -Ken

Re: [Module::Build] Asking the unaskable

[John P. <jpe...@ro...>]

David Golden wrote:
> Module::Install bundles itself in the distribution -- you don't need
> to worry about what version of the install toolchain is present on
> users' machines.

Unfortunately, that's not currently true in practice.  See the second 
entry on this ticket:

	http://rt.cpan.org/Public/Bug/Display.html?id=14732

I haven't had the time to make a formal bug report to M::I, but it 
appears that recent changes in the M::I API may break existing installs 
with no recourse for the normal user.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Re: [Module::Build] Asking the unaskable

[John P. <jpe...@ro...>]

Johan Vromans wrote:
> I'm writing this new and flashy application (some scripts, modules,
> and data -- pure perl). Should I use ExtUtils::MakeMaker,
> Module::Build or Module::Install?

<vorlon>Module installation is a three-edged sword</vorlon>

ExtUtils::MakeMaker is installed by core Perl going back to the depths 
of history, but the API is very convoluted, so anything out of the 
ordinary is difficult.  If you don't have any unusual needs, this is 
most likely to Just Work(TM) everywhere.

Module::Install is intended to be a better interface to creating a 
Makefile, but it is still fairly new and (IMHO) a little rough around 
the edges (especially the POD).  It has the big advantage of not 
requiring the _user_ to install anything else (since the M::I files are 
included in the distro).

Module::Build is more mature than M::I, but more designed for reuse than 
EU::MM.  It does require that the user install M::B before they can 
install your module, but recent Bundle::CPANPLUS and Bundle::CPAN both 
install M::B first.  M::B has been added to bleadperl (with some degree 
of success) and is intended to be core in v5.10.0.

I'm using Module::Build going forward for all of my modules, because I 
find I can do more intelligent installers.  YMMV.

HTH

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Re: [Module::Build] Asking the unaskable

[David G. <da...@hy...>]

Johan Vromans wrote:
> For a while now I've been trying to follow de developments in the
> Module::* area. There's a question that's bugging me. It's probably
> 'not done' to ask it. Nevertheless, I do.
> 
> I'm writing this new and flashy application (some scripts, modules,
> and data -- pure perl). Should I use ExtUtils::MakeMaker,
> Module::Build or Module::Install?

At this point, with CPAN.pm support for Module::Build improved, and 
Module::Build going into the core in blead, I think Module::Build has 
the edge over ExtUtils::MakeMaker.

Module::Install is a tougher question.  Honestly, I think it may come 
down to your philosophy about installers.  Module::Install bundles 
itself in the distribution -- you don't need to worry about what version 
   of the install toolchain is present on users' machines.  On the other 
hand, you need to re-release your module each time critical bugs are 
found in Module::Install.

You might want to see this journal entry for Adam Kennedy for some 
additional thoughts:
http://use.perl.org/~Alias/journal/28855

Personally, I think that Module::Install is solving a problem that will 
be going away with the latest releases of CPAN.pm and Module::Build -- 
but you then have to rely upon users to upgrade CPAN.pm and 
Module::Build accordingly.

On the other hand, I like that it can bundle my "build_requires" modules 
-- but there's no reason you can't do that by hand already if you really 
need to.

Regards,
David

[Module::Build] Asking the unaskable

[Johan V. <jvr...@sq...>]

For a while now I've been trying to follow de developments in the
Module::* area. There's a question that's bugging me. It's probably
'not done' to ask it. Nevertheless, I do.

I'm writing this new and flashy application (some scripts, modules,
and data -- pure perl). Should I use ExtUtils::MakeMaker,
Module::Build or Module::Install?

-- Johan

[Module::Build] Re: New ExtUtils::CBuilder -> CPAN

[Rafael Garcia-S. <rga...@gm...>]

On 3/17/06, Randy W. Sims <ml...@th...> wrote:
> Attached is a patch that will bring blead up to date.
>
Thanks, applied as #27531.

[Module::Build] How to I specify in META.yml a package needs a C compiler?

[R. B. <ro...@pa...>]

dlisp options from Kobe's CPAN search I think use META.yml and
META.yml is set via Module::Build. I have a package that requires a C
compiler, but dlisp/META.ymal doesn't show that. How do I specify that
(e.g. in Build.PL)?

Thanks.

[Module::Build] Re: New ExtUtils::CBuilder -> CPAN

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

Randy W. Sims wrote:
> Ken Williams wrote:
>> Hi,
>>
>> Based on feedback we've gotten since Module::Build went into 
>> bleadperl, I've released ExtUtils::CBuilder 0.17 with the following 
>> changes since 0.16:
>>
>> 0.17  Wed Mar 15 22:46:15 CST 2006
>>
>>  - When we're being run from an uninstalled perl distribution
>>    (e.g. one that's in the process of being built and tested), we
>>    search for perl first in the current working directory. [Randy
>>    Sims]
>>
>>  - More fixing of the arg_defines() method on VMS. [Craig A. Berry and
>>    John E. Malmberg]
>>
>>
>> Should be suitable for blead integration when it hits CPAN.
> 
> Attached is a patch that will bring blead up to date.
> 

BTW, the patch adds one file:

  lib/ExtUtils/CBuild/Changes

[Module::Build] Re: New ExtUtils::CBuilder -> CPAN

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

Ken Williams wrote:
> Hi,
> 
> Based on feedback we've gotten since Module::Build went into bleadperl, 
> I've released ExtUtils::CBuilder 0.17 with the following changes since 
> 0.16:
> 
> 0.17  Wed Mar 15 22:46:15 CST 2006
> 
>  - When we're being run from an uninstalled perl distribution
>    (e.g. one that's in the process of being built and tested), we
>    search for perl first in the current working directory. [Randy
>    Sims]
> 
>  - More fixing of the arg_defines() method on VMS. [Craig A. Berry and
>    John E. Malmberg]
> 
> 
> Should be suitable for blead integration when it hits CPAN.

Attached is a patch that will bring blead up to date.

Randy.

[Module::Build] compatability matrix

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

I've added version information to the docs, indicating the version when 
each feature, action, constructor argument, and method was first 
publicly documented.

Attached is my (open office 2.0) source file for those interested.

Randy.

[Module::Build] New ExtUtils::CBuilder -> CPAN

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

Hi,

Based on feedback we've gotten since Module::Build went into  
bleadperl, I've released ExtUtils::CBuilder 0.17 with the following  
changes since 0.16:

0.17  Wed Mar 15 22:46:15 CST 2006

  - When we're being run from an uninstalled perl distribution
    (e.g. one that's in the process of being built and tested), we
    search for perl first in the current working directory. [Randy
    Sims]

  - More fixing of the arg_defines() method on VMS. [Craig A. Berry and
    John E. Malmberg]


Should be suitable for blead integration when it hits CPAN.

  -Ken

Re: [Module::Build] add_property()

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

On Mar 15, 2006, at 17:57, Randy W. Sims wrote:

> $builder->add_build_element('yml');
> $builder->install_path(
>     'yml' => File::Spec->catdir($builder->install_base, 'etc'),
> );
>
> $builder->create_build_script;

Nice.

> The constructor tells it to copy the 'config.yml' in the root  
> directory of your distribution (the directory containing  
> 'Build.PL') and copy it to 'blib/yml/config.yml'.
>
> The call to install_path tells it where to install the yml files  
> relative to install_base. In the above example it would install into
>
>   /home/randys/tmp/Foo/etc/config.yml

Cool, as long as install_base doesn't change after the call to  
install_path(). :-) Since that's a problem that I have, I eagerly  
await your auto_build_elements() method.

Best,

David

Re: [Module::Build] add_property()

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

Peter Scott wrote:
> At 03:40 AM 3/9/2006, Randy W. Sims wrote:

>> As of current cvs the way I would probably write this is:
>>
>> use strict;
>> use warnings;
>>
>> use Module::Build;
>>
>> my $build_class = Module::Build->subclass(code => <<'EOC');
>>
>>   sub new {
>>       my $class = shift;
>>       my $self  = $class->SUPER::new(@_);
>>
>>       $self->install_path->{'yml'} =
>>           $self->localize_file_path($self->install_base . '/etc');
>>
>>       return $self;
>>   }
>>
>> EOC
>>
>> my $builder = $build_class->new(
>>     dist_name         => 'Foo',
>>     dist_version_from => 'lib/Foo.pm',
>>
>>     install_base      => '/home/randys/tmp/Foo',
>>
>>     yml_files         => {'config.yml' => 'yml/config.yml'},


I've documented the install_path() accessor now, so the above becomes:

use strict;
use warnings;

use File::Spec;

use Module::Build;
my $builder = Module::Build->new(
     dist_name         => 'Foo',
     dist_version_from => 'lib/Foo.pm',

     install_base      => '/home/randys/tmp/Foo',

     yml_files         => {'config.yml' => 'yml/config.yml'},
);

$builder->add_build_element('yml');
$builder->install_path(
     'yml' => File::Spec->catdir($builder->install_base, 'etc'),
);

$builder->create_build_script;

__END__

The constructor tells it to copy the 'config.yml' in the root directory 
of your distribution (the directory containing 'Build.PL') and copy it 
to 'blib/yml/config.yml'.

The call to install_path tells it where to install the yml files 
relative to install_base. In the above example it would install into

   /home/randys/tmp/Foo/etc/config.yml


> What wasn't obvious until I spent some time doing it wrong was that the 
> config.yml above *must* be in a subdirectory called 'yml'.  I had 
> initially called it 'etc' and finally hauled out the debugger which led 
> me to where the code does
> 
>  my $localdir = File::Spec->catdir( $blib, $type );
> 
> That was something I did not glean at all from reading the "Adding new 
> file types to the install process" section of the cookbook, which 
> somehow avoids having to put .dat files into a /dat directory.

I'll see if that can be cleared up some; maybe another recipe in the 
Cookbook.

Also, I'm off to backpan to retrieve every release version of 
Module::Build. I'm going to scan the docs and make a compatibility 
matrix to document when each method/accessor was added. I'll add it to 
the docs as a note under each heading like:

=install_path()

[version 0.28]

blah blah...

=cut

If I can figure a way to draw out the matrix itself, I'll find a place 
to put it.

Randy.

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

[Yitzchak Scott-T. <sth...@ef...>]

On Sun, Mar 12, 2006 at 12:15:40PM -0600, Steve Peters wrote:
> On Sun, Mar 12, 2006 at 03:01:29AM -0500, Randy W. Sims wrote:
> > Ken Williams wrote:
> > >Hi,
> > >
> > >I've just released M::B 0.27_09 with the following changes.  In  
> > >particular, when I use this copy of Module/Build.pm in bleadperl, all  
> > >the M::B-related tests now pass (though with considerable complaining).
> > >
> > >
> > >0.27_09  Sat Mar 11 22:48:54 EST 2006
> > 
> > Attached is a patch against bleed.
> > 
> 
> Randy,
> 
> Actually, I patched Module::Build before I read your email, but thanks
> anyways :)
> 
> Module::Build was updated in bleadperl with change #27841. 

Steve, Randy, I'm almost certain there is no difference this time
around, but for the future, please note that bleadperl contains the
Module/Build/ConfigData.pm which you have to generate (run Build.PL
and Build on the CPAN dist and pull it out of blib/).

Re: [Module::Build] Re: Module::Build 0.27_09 -> CPAN

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

Ken Williams wrote:
> Hi Randy,
> 
> I think the find_perl_interpreter() and perl_is_same() methods are 
> getting uglier and uglier (i.e. they're getting more special-casing), 
> which is just fine as long as they work, but I think I'm going to want 
> to clean them up at some point.  Which means we need to have tests that 
> will exercise the various cases we're covering, or else I'll probably 
> break something.
> 
> I know that's going to pretty hard to do, but maybe a first step would 
> be just to list the specific cases we indeed cover, right in the 
> corresponding code.
> 
> I say go ahead and check this in to fix breakage, and let's try to 
> fairly quickly (before we forget) add those comments.

Added with copious comments.

I'm not sure how you want to handle release. There really isn't anything 
to justify a CPAN release. Should we just generate a patch against 
blead? Then wait for more the smokes to clear before making an actual 
release?

Randy.

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

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

Hi Randy,

I think the find_perl_interpreter() and perl_is_same() methods are  
getting uglier and uglier (i.e. they're getting more special-casing),  
which is just fine as long as they work, but I think I'm going to  
want to clean them up at some point.  Which means we need to have  
tests that will exercise the various cases we're covering, or else  
I'll probably break something.

I know that's going to pretty hard to do, but maybe a first step  
would be just to list the specific cases we indeed cover, right in  
the corresponding code.

I say go ahead and check this in to fix breakage, and let's try to  
fairly quickly (before we forget) add those comments.

  -Ken


On Mar 14, 2006, at 5:04 AM, Randy W. Sims wrote:

> Attached are my final suggested patches for MB & EUCB.
>
> Note that I've restricted the search for the perl interpreter so  
> that it does not search in the PATH if PERL_CORE is set as I  
> believe this is more correct. In practice this has no effect on any  
> system I've tested on because we always find it where we expect now.
>
> Also, find_perl_interpreter now throws an exception if it fails.
>
> If this is sensible I can check it in and generate a patch for blead.
>
> Randy.
> Index: lib/ExtUtils/CBuilder/Base.pm
> ===================================================================
> RCS file: /cvsroot/module-build/ExtUtils-CBuilder/lib/ExtUtils/ 
> CBuilder/Base.pm,v
> retrieving revision 1.19
> diff -u -r1.19 Base.pm
> --- lib/ExtUtils/CBuilder/Base.pm	3 Oct 2005 22:05:14 -0000	1.19
> +++ lib/ExtUtils/CBuilder/Base.pm	14 Mar 2006 10:51:19 -0000
> @@ -240,11 +240,11 @@
>
>    return unless $ENV{PERL_CORE};
>
> -  my $Updir  = File::Spec->updir;
> -  my $dir = $Updir;
> +  my $Updir = File::Spec->updir;
> +  my $dir   = File::Spec->curdir;
>
>    # Try up to 5 levels upwards
> -  for (1..5) {
> +  for (0..5) {
>      if (
>  	-f File::Spec->catfile($dir,"config_h.SH")
>  	&&
> @@ -257,9 +257,9 @@
>
>      $dir = File::Spec->catdir($dir, $Updir);
>    }
> -
> +
>    warn "PERL_CORE is set but I can't find your perl source!\n";
> -  return;
> +  return ''; # return empty string if $ENV{PERL_CORE} but can't  
> find dir ???
>  }
>
>  # directory of perl's include files
> Index: lib/Module/Build/Base.pm
> ===================================================================
> RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/ 
> Base.pm,v
> retrieving revision 1.558
> diff -u -r1.558 Base.pm
> --- lib/Module/Build/Base.pm	11 Mar 2006 03:06:20 -0000	1.558
> +++ lib/Module/Build/Base.pm	14 Mar 2006 10:50:37 -0000
> @@ -12,7 +12,6 @@
>  use Data::Dumper ();
>  use IO::File ();
>  use Text::ParseWords ();
> -use Carp ();
>
>  use Module::Build::ModuleInfo;
>  use Module::Build::Notes;
> @@ -317,37 +316,67 @@
>
>  sub _perl_is_same {
>    my ($self, $perl) = @_;
> -  return `$perl -MConfig=myconfig -e print -e myconfig` eq Config- 
> >myconfig;
> +
> +  my $INC = '';
> +  if ($ENV{PERL_CORE}) {
> +    $INC = '-I' . File::Spec->catdir(File::Basename::dirname 
> ($perl), 'lib');
> +  }
> +
> +  return `$perl $INC -MConfig=myconfig -e print -e myconfig` eq  
> Config->myconfig;
>  }
>
>  sub find_perl_interpreter {
> -  return $^X if File::Spec->file_name_is_absolute($^X);
>    my $proto = shift;
> -  my $c = ref($proto) ? $proto->config : \%Config::Config;
> -  my $exe = $c->{exe_ext};
> +  my $c     = ref($proto) ? $proto->config : \%Config::Config;
>
> -  my $thisperl = $^X;
> -  if ($proto->os_type eq 'VMS') {
> -    # VMS might have a file version at the end
> -    $thisperl .= $exe unless $thisperl =~ m/$exe(;\d+)?$/i;
> -  } elsif (defined $exe) {
> -    $thisperl .= $exe unless $thisperl =~ m/$exe$/i;
> -  }
> +  my @potential_perls;
> +
> +  my $perl  = $^X;
> +  push( @potential_perls, $perl )
> +      if File::Spec->file_name_is_absolute($perl);
> +
> +  my $abs_perl = File::Spec->rel2abs($perl);
> +  push( @potential_perls, $abs_perl );
> +
> +  my $perl_basename = File::Basename::basename($perl);
>
> -  my $uninstperl;
>    if ($ENV{PERL_CORE}) {
> +
>      # CBuilder is also in the core, so it should be available here
>      require ExtUtils::CBuilder;
> -    $uninstperl = File::Spec->catfile(ExtUtils::CBuilder::- 
> >perl_src, $thisperl);
> +    my $perl_src = ExtUtils::CBuilder->perl_src;
> +    if ( defined($perl_src) && length($perl_src) ) {
> +      my $uninstperl =
> +        File::Spec->rel2abs(File::Spec->catfile( $perl_src,  
> $perl_basename ));
> +      push( @potential_perls, $uninstperl );
> +    }
> +
> +  } else {
> +
> +    push( @potential_perls, $c->{perlpath} );
> +
> +    push( @potential_perls,
> +          map File::Spec->catfile($_, $perl_basename), File::Spec- 
> >path() );
>    }
>
> -  foreach my $perl ( $uninstperl || (),
> -                     $c->{perlpath},
> -		     map File::Spec->catfile($_, $thisperl), File::Spec->path()
> -		   ) {
> -    return $perl if -f $perl and $proto->_perl_is_same($perl);
> +  my $exe = $c->{exe_ext};
> +  foreach my $thisperl ( @potential_perls ) {
> +
> +    if ($proto->os_type eq 'VMS') {
> +      # VMS might have a file version at the end
> +      $thisperl .= $exe unless $thisperl =~ m/$exe(;\d+)?$/i;
> +    } elsif (defined $exe) {
> +      $thisperl .= $exe unless $thisperl =~ m/$exe$/i;
> +    }
> +
> +    if ( -f $thisperl && $proto->_perl_is_same($thisperl) ) {
> +      return $thisperl;
> +    }
>    }
> -  return;
> +
> +  my @paths = map File::Basename::dirname($_), @potential_perls;
> +  die "Can't locate the perl binary used to run this script " .
> +      "in (@paths)\n";
>  }
>
>  sub _is_interactive {
> @@ -1235,8 +1264,7 @@
>  use $build_package;
>
>  # Some platforms have problems setting \$^X in shebang contexts,  
> fix it up here
> -\$^X = Module::Build->find_perl_interpreter
> -  unless File::Spec->file_name_is_absolute(\$^X);
> +\$^X = Module::Build->find_perl_interpreter;
>
>  if (-e 'Build.PL' and not $build_package->up_to_date('Build.PL', \ 
> $progname)) {
>     warn "Warning: Build.PL has been altered.  You may need to run  
> 'perl Build.PL' again.\\n";

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

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

Andy Dougherty wrote:
> On Mon, 13 Mar 2006, Ken Williams wrote:
> 
> 
>>On Mar 13, 2006, at 8:02 PM, Randy W. Sims wrote:
>>
>>
>>>This is what happens. It looks at several potential perls, and for each one,
>>>compares the configuration to see if it's the same perl that is currently
>>>executing. The problem is that when it executes the perl binary it finds in
>>>the core, it doesn't pass in the correct include directory for it to find
>>>Config.pm, so the test fails and it continues the search by looking in the
>>>PATH.
>>
>>I have a little theory that in some cases it's actually the reverse - our @INC
>>is set to find modules in the not-yet-installed perl (otherwise no modules
>>would be able to load, and they do load), but we're testing out other perls
>>and *they* can't find an appropriate Config.pm.
> 
> 
> Yes, in some cases it's the reverse.  In the first error message I posted, 
> it's the just-built perl that's complaining.  In the second error message, 
> it's an old perl5.00503.  
> 
> I'm happy to report that in both cases, however, Randy's patch works!
> 
> Thanks!
> 

Attached are my final suggested patches for MB & EUCB.

Note that I've restricted the search for the perl interpreter so that it 
does not search in the PATH if PERL_CORE is set as I believe this is 
more correct. In practice this has no effect on any system I've tested 
on because we always find it where we expect now.

Also, find_perl_interpreter now throws an exception if it fails.

If this is sensible I can check it in and generate a patch for blead.

Randy.

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

[Dominic D. <sho...@ma...>]

On 2006=9603=9614, at 03:02, Randy W. Sims wrote:
> Attached is a working (not final) patch that works for me on =20
> FreeBSD, Ubuntu Linux, Windows XP, and cygwin. Could you please =20
> give it a spin?

Also results in all tests passing on Mac OS X. Thanks!

$ ./TEST ../lib/Module/Build/t/*.t
t/../lib/Module/Build/t/basic...........ok
t/../lib/Module/Build/t/compat..........ok
t/../lib/Module/Build/t/destinations....ok
t/../lib/Module/Build/t/ext.............ok
t/../lib/Module/Build/t/extend..........ok
t/../lib/Module/Build/t/files...........ok
t/../lib/Module/Build/t/install.........ok
t/../lib/Module/Build/t/manifypods......ok
t/../lib/Module/Build/t/metadata........ok
t/../lib/Module/Build/t/metadata2.......ok
t/../lib/Module/Build/t/moduleinfo......ok
t/../lib/Module/Build/t/notes...........ok
t/../lib/Module/Build/t/parents.........ok
t/../lib/Module/Build/t/pod_parser......ok
t/../lib/Module/Build/t/ppm.............ok
t/../lib/Module/Build/t/runthrough......ok
t/../lib/Module/Build/t/signature.......skipping test on this platform
t/../lib/Module/Build/t/tilde...........ok
t/../lib/Module/Build/t/versions........ok
t/../lib/Module/Build/t/xs..............ok
All tests successful.
u=3D0.24  s=3D0.11  cu=3D91.17  cs=3D50.73  scripts=3D19  tests=3D663

(That was a threaded bleadperl@27491.)

Previously, there had been two failures:

lib/Module/Build/t/ext.....................................PERL_CORE =20
is set but I can't find your perl source!
Perl lib version (5.9.4) doesn't match executable version (v5.8.6) =20
at /Volumes/Tottie/Other/src/Perl/perl-current-working/lib/Config.pm =20
line 46.
Compilation failed in require.
BEGIN failed--compilation aborted.
Perl lib version (5.9.4) doesn't match executable version (v5.8.6) =20
at /Volumes/Tottie/Other/src/Perl/perl-current-working/lib/Config.pm =20
line 46.
Compilation failed in require.
BEGIN failed--compilation aborted.
PERL_CORE is set but I can't find your perl source!
Use of uninitialized value $perl in concatenation (.) or string at /=20
Volumes/Tottie/Other/src/Perl/perl-current-working/t/../lib/Module/=20
Build/Base.pm line 1162.
sh: - : invalid option
Use of uninitialized value $cmd[0] in join or string at /Volumes/=20
Tottie/Other/src/Perl/perl-current-working/t/../lib/Module/Build/=20
Base.pm line 3726.
Use of uninitialized value $cmd[0] in system at /Volumes/Tottie/Other/=20=

src/Perl/perl-current-working/t/../lib/Module/Build/Base.pm line 3727.
Can't exec "": No such file or directory at /Volumes/Tottie/Other/src/=20=

Perl/perl-current-working/t/../lib/Module/Build/Base.pm line 3727.
#   Failed test in ../lib/Module/Build/t/ext.t at line 100.
#                   ' -le print for @INC
# '
#     doesn't match '(?m-xis:^whosiewhatzit)'
# Looks like you failed 1 test of 92.
FAILED at test 92
...
lib/Module/Build/t/compat..................................sh: - : =20
invalid option
Couldn't run Build.PL: No such file or directory at /Volumes/Tottie/=20
Other/src/Perl/perl-current-working/t/../lib/Module/Build/Compat.pm =20
line 199.
#   Failed test in ../lib/Module/Build/t/compat.t at line 180.
#   Failed test 'Makefile should exist'
#   in ../lib/Module/Build/t/compat.t at line 181.
make[3]: *** No targets specified and no makefile found.  Stop.
FAILED at test 3

and vast numbers of "uninitialized value" warnings, even when tests =20
passed.
--=20
Dominic Dunlop

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

[Andy D. <dou...@la...>]

On Mon, 13 Mar 2006, Ken Williams wrote:

> 
> On Mar 13, 2006, at 8:02 PM, Randy W. Sims wrote:
> 
> > This is what happens. It looks at several potential perls, and for each one,
> > compares the configuration to see if it's the same perl that is currently
> > executing. The problem is that when it executes the perl binary it finds in
> > the core, it doesn't pass in the correct include directory for it to find
> > Config.pm, so the test fails and it continues the search by looking in the
> > PATH.
> 
> I have a little theory that in some cases it's actually the reverse - our @INC
> is set to find modules in the not-yet-installed perl (otherwise no modules
> would be able to load, and they do load), but we're testing out other perls
> and *they* can't find an appropriate Config.pm.

Yes, in some cases it's the reverse.  In the first error message I posted, 
it's the just-built perl that's complaining.  In the second error message, 
it's an old perl5.00503.  

I'm happy to report that in both cases, however, Randy's patch works!

Thanks!

-- 
    Andy Dougherty		dou...@la...

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

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

On Mar 13, 2006, at 8:02 PM, Randy W. Sims wrote:

> This is what happens. It looks at several potential perls, and for  
> each one, compares the configuration to see if it's the same perl  
> that is currently executing. The problem is that when it executes  
> the perl binary it finds in the core, it doesn't pass in the  
> correct include directory for it to find Config.pm, so the test  
> fails and it continues the search by looking in the PATH.

I have a little theory that in some cases it's actually the reverse -  
our @INC is set to find modules in the not-yet-installed perl  
(otherwise no modules would be able to load, and they do load), but  
we're testing out other perls and *they* can't find an appropriate  
Config.pm.

Or in general: if our @INC is inappropriate to the perls we're  
testing, then we'll see this kind of behavior.  Maybe there's a way  
to short-circuit early?  Compare 'perl -v' before comparing 'Config- 
 >myconfig' perhaps?

  -Ken

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

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

Andy Dougherty wrote:
>>> Ken Williams wrote:
> 
>>>> I've just released M::B 0.27_09 with the following changes.  In  
>>>> particular, when I use this copy of Module/Build.pm in bleadperl, all  
>>>> the M::B-related tests now pass (though with considerable complaining).
> 
> Alas, this still fails for me.  I build perl on Solaris with a symlink tree
> 
> 	sh ../perl-current/Configure -Dmksymlinks -Dprefix=/tmp/perl -des
> 
> and the Module Build tests still fail.  Here's a sample:
> 
> ../lib/Module/Build/t/basic..................................Can't locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4-solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4-solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .).
> BEGIN failed--compilation aborted.
> Use of uninitialized value $perl in concatenation (.) or string at /home/doughera/src/perl/perl-andy/t/../lib/Module/Build/Base.pm line 1162.
> sh: -le: not found
> 
> Here's another sample:
> 
> ../lib/Module/Build/t/ext....................................PERL_CORE is set but I can't find your perl source!
> Bareword "our" not allowed while "strict subs" in use at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
> Bareword "Config" not allowed while "strict subs" in use at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
> Operator or semicolon missing before %Config at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
> Ambiguous use of % resolved as operator % at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
> BEGIN not safe after errors--compilation aborted at /home/doughera/src/perl/perl-andy/lib/Config.pm line 31.
> BEGIN failed--compilation aborted.
> 
> I think the other error messages here are because the test apparently
> picked up an older perl (probably 5.00503) installed elsewhere in my
> PATH.

This is what happens. It looks at several potential perls, and for each 
one, compares the configuration to see if it's the same perl that is 
currently executing. The problem is that when it executes the perl 
binary it finds in the core, it doesn't pass in the correct include 
directory for it to find Config.pm, so the test fails and it continues 
the search by looking in the PATH.

Attached is a working (not final) patch that works for me on FreeBSD, 
Ubuntu Linux, Windows XP, and cygwin. Could you please give it a spin?

Thanks,
Randy.

> Strangely enough, despite those failures, the test_harness target still
> reported all tests successful:
> 
> All tests successful (5 subtests UNEXPECTEDLY SUCCEEDED), 63 tests and 323 subtests skipped.
> 

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

[Andy D. <dou...@la...>]

> > Ken Williams wrote:

> > >I've just released M::B 0.27_09 with the following changes.  In  
> > >particular, when I use this copy of Module/Build.pm in bleadperl, all  
> > >the M::B-related tests now pass (though with considerable complaining).

Alas, this still fails for me.  I build perl on Solaris with a symlink tree

	sh ../perl-current/Configure -Dmksymlinks -Dprefix=/tmp/perl -des

and the Module Build tests still fail.  Here's a sample:

../lib/Module/Build/t/basic..................................Can't locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4-solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4-solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .).
BEGIN failed--compilation aborted.
Use of uninitialized value $perl in concatenation (.) or string at /home/doughera/src/perl/perl-andy/t/../lib/Module/Build/Base.pm line 1162.
sh: -le: not found

Here's another sample:

../lib/Module/Build/t/ext....................................PERL_CORE is set but I can't find your perl source!
Bareword "our" not allowed while "strict subs" in use at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
Bareword "Config" not allowed while "strict subs" in use at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
Operator or semicolon missing before %Config at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
Ambiguous use of % resolved as operator % at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
BEGIN not safe after errors--compilation aborted at /home/doughera/src/perl/perl-andy/lib/Config.pm line 31.
BEGIN failed--compilation aborted.

I think the other error messages here are because the test apparently
picked up an older perl (probably 5.00503) installed elsewhere in my
PATH.

Strangely enough, despite those failures, the test_harness target still
reported all tests successful:

All tests successful (5 subtests UNEXPECTEDLY SUCCEEDED), 63 tests and 323 subtests skipped.

-- 
    Andy Dougherty		dou...@la...

Re: [Module::Build] Re: [PATCH] add Module::Build 0.27_08

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

Randy W. Sims wrote:
> Randy W. Sims wrote:
> 
>> Unfortunately, I don't have a broken system to test on so I'm mostly 
>> guessing. I do have an old 633 Mhz Pentium PC laying around somewhere 
>> that I can install one of the BSD variant on tonight or tomorrow.
> 
> I've been taking my time getting my BSD test system up because I was 
> assuming from previous reports that the BSD issue was mostly fixed. I 
> finally got it up and configured enough to do some testing, and it looks 
> like there are still failures because of the same issue, mostly.
> 
> The attached patch is my rough working code to get it fixed.
> 
> Module::Build::Base::_perl_is_same needs to set @INC in order to find 
> Config.pm when $ENV{PERL_CORE}. Is there a better alternative?
> 
> ExtUtils::CBuilder::Base::perl_src needs to check in the current 
> directory before moving up. Well, maybe. This really is just a result of 
> the way I rewrote Module::Build::Base::find_perl_interpreter to collect 
> a list of /all/ candidates before testing for the correct one. If $perl 
> and $abs_perl where tested and successful, we could return before the 
> call to perl_src(). It's not really a problem except for the spurious 
> warning about not find the perl source.
> 
> This is tested on FreeBSD 6.0 & Ubuntu Linux. I'll test later on Windows 
> & Cygwin.

Ok. With this patch I get no errors, warnings, or any noise on the above 
mentioned four platforms.

Any comments on the implementation? The only iffy part from my point of 
view is the _perl_is_same method. Is it the best way to handle this?

One other minor change I'd like to make that'd not in the patch is to 
change ExtUtils::CBuilder::perl_src to not emit a warning, leaving it up 
to the caller to emit a warning if needed.

Other that that, I think the basics are all correct for most platforms.

Randy.

[Module::Build] Re: [PATCH] VMS-specific arg_defines for CBuilder

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

On Mar 13, 2006, at 5:12 PM, Craig Berry wrote:

> On Monday, March 13, 2006, at 04:06PM, Ken Williams  
> <ke...@ma...> wrote:
>
>> BTW, is there a regression test that could have exposed this issue?
>>
>>  -Ken
>
> It did show up in a number of the Module::Build failures, such as  
> xs.t.  Anything compiling XS-generated C would hit it since the  
> version is defined on the command line.

Okay, thanks.

I've released this patch in the new EU::CBuilder 0.16, ripe for blead  
integration.

  -Ken

[Module::Build] Re: [PATCH] VMS-specific arg_defines for CBuilder

[Craig B. <cra...@ma...>]

On Monday, March 13, 2006, at 04:06PM, Ken Williams <ke...@ma...> wrote:

>BTW, is there a regression test that could have exposed this issue?
>
>  -Ken

It did show up in a number of the Module::Build failures, such as xs.t.  Anything compiling XS-generated C would hit it since the version is defined on the command line.

>On Mar 12, 2006, at 7:37 PM, Ken Williams wrote:
>
>> Thanks Craig.  Yup, CBuilder is separately maintained, the nexus  
>> for development is often the Module::Build list.
>>
>> I'll apply this patch and make a new release.
>>
>>  -Ken
>>
>>
>> On Mar 12, 2006, at 6:01 PM, Craig A. Berry wrote:
>>
>>> The attached provides the special handling needed for C compiler  
>>> defines
>>> in ExtUtils::CBuilder. This is against blead but I'm hoping the right
>>> number after -p supplied to patch will apply cleanly to the CPAN  
>>> version
>>> (which is separately maintained, right?).
>>> --- lib/ExtUtils/CBuilder/Platform/VMS.pm;-0	Wed Sep 28 19:54:07 2005
>>> +++ lib/ExtUtils/CBuilder/Platform/VMS.pm	Sat Mar 11 17:53:09 2006
>>> @@ -9,6 +9,21 @@ $VERSION = '0.12';
>>>
>>>  sub need_prelink { 0 }
>>>
>>> +sub arg_defines {
>>> +  my ($self, %args) = @_;
>>> +
>>> +  s/"/""/g foreach values %args;
>>> +
>>> +  my $config_defines = '';
>>> +
>>> +  # VMS can only have one define qualifier; add the one from  
>>> config, if any.
>>> +  if ($self->{config}{ccflags} =~ s{/def[^=]+(?:=)+(?:\()?([^\/\)] 
>>> *)} {}i) {
>>> +    $config_defines = "$1,";
>>> +  }
>>> +
>>> +  return ('/define=(' . $config_defines . join(',', map "\"$_= 
>>> $args{$_}\"", keys %args) . ')');
>>> +}
>>> +
>>>  sub arg_include_dirs {
>>>    my ($self, @dirs) = @_;
>>>
>>
>
>
>