New Module::Build beta

Hi,

I'd be obliged if people could send smoke reports for the following,  
particularly reports of integrating with blead.  Thanks.

  -Ken

The uploaded file

     Module-Build-0.2805_01.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.2805_01.tar.gz
   size: 188232 bytes
    md5: 181fdc54f741216d19c5cf479e3a79c9

Changes since 0.2805:

  - Because of a weird behavior of YAML::Node, any distribution that
    used version.pm objects to define their versions was generating the
    wrong syntax for the versions in their META.yml file.  They will
    now appear as strings like v3.42.1 or similar, including the
    leading v.

- Upgraded to version 0.67 of version.pm. [John Peacock]

- Added a contrib/ directory with a bash completion function for M::B
    actions and switches. [Julian Mehnle]

[PATCH] Some VMS help (Re: New Module::Build beta)

On 9/7/06, Ken Williams <ken <at> mathforum.org> wrote:

> I'd be obliged if people could send smoke reports for the following,
> particularly reports of integrating with blead.  Thanks.

The attached patch against 2805_01 gets the failure rate to 9/21 on
VMS, down from something in the high teens.  Obviously there's still a
lot of work to do, but this gets a lot of basic things working and
does not affect any code run on other plaforms.

Re: [PATCH] Some VMS help (Re: New Module::Build beta)

Awesome, thanks Craig!  I've committed your patch verbatim.

  -Ken

On Sep 9, 2006, at 4:58 PM, Craig Berry wrote:

> The attached patch against 2805_01 gets the failure rate to 9/21 on
> VMS, down from something in the high teens.  Obviously there's still a
> lot of work to do, but this gets a lot of basic things working and
> does not affect any code run on other plaforms.
> <mb.patch>

Re: Installing Tests

Ovid wrote:
> Last week I was at a testing conference with Acme and he came up with the idea of installing tests.  He looked
into hacking Module::Build and ExtUtils::MakeMaker.  He also considered hacking CPAN.pm and
CPANPLUS.pm.  While I don't know if he plans to continue working on this idea, he said he didn't mind me
posting his idea here for others to consider.
> 
> Basically, installing tests would be good because then you can run your full test suite against
*installed* modules.  That would be nice because then you could install a module and rerun your tests for
your entire installation and see what broke.
> 
> I love this idea, but here are some issues that we spotted:
> 
> 1.  How does one install tests for modules already installed?
> 2.  If you install a module with already failing tests, you need to track what the failures are so you can note
different failures when you run the test suite in the future.
> 3.  What's the best way to install them?  Should a separate tool just for this be built?
> 
> Anyone want to take a crack at this?
> 
> I'm also going to post this to Perlmonks.

IIRC, I think this is something Ken has had in mind for a long time for 
Module::Build. He might have some ideas about how it might be done.

Randy.

Re: Installing Tests

On Sep 11, 2006, at 7:08 PM, Randy W. Sims wrote:

> Ovid wrote:
>> Last week I was at a testing conference with Acme and he came up  
>> with the idea of installing tests.  He looked into hacking  
>> Module::Build and ExtUtils::MakeMaker.  He also considered hacking  
>> CPAN.pm and CPANPLUS.pm.  While I don't know if he plans to  
>> continue working on this idea, he said he didn't mind me posting  
>> his idea here for others to consider.
>> Basically, installing tests would be good because then you can run  
>> your full test suite against *installed* modules.  That would be  
>> nice because then you could install a module and rerun your tests  
>> for your entire installation and see what broke.
>> I love this idea, but here are some issues that we spotted:
>> 1.  How does one install tests for modules already installed?
>> 2.  If you install a module with already failing tests, you need  
>> to track what the failures are so you can note different failures  
>> when you run the test suite in the future.
>> 3.  What's the best way to install them?  Should a separate tool  
>> just for this be built?
>> Anyone want to take a crack at this?
>> I'm also going to post this to Perlmonks.
>
> IIRC, I think this is something Ken has had in mind for a long time  
> for Module::Build. He might have some ideas about how it might be  
> done.

Yes, I've been thinking about this for a long time.  In fact, in the  
most recent M::B beta I made some steps toward it, by adding a  

Irony? Module::Build cannot itself be built.

All:

I've been working through this problem and after digging through the
mailing list archives and various bug reports, I'm seemingly no closer
to a resolution than when I started.

The problem is that I seemingly cannot get Module::Build to...wait for
it...build.  The platform:  RedHat Enterprise Linux 4 (Update 4).

I've tried this patch:

+
+  my %seen;
+  local $ENV{PERL5LIB} = join $self->config->{path_sep}, grep {
+    ! $seen{$_}++ and -d $_
+  } split($self->config->{path_sep}, $ENV{PERL5LIB});
+
+

This patch:

  my %seen;
  local $ENV{PERL5LIB} =3D join(':', grep({
    ! $seen{$_}++ and -d $_
  } split(/:/, $ENV{PERL5LIB})));

Building from subversion:

  svn export https://svn.perl.org/modules/Module-Build/trunk mb
  perl Build.PL

Re: Irony? Module::Build cannot itself be built.

Hi David,

If you want a patch that will make the tests succeed, I bet the  
attached would do it.

Is it the right solution?  Beats me.  I still haven't gotten my hands  
on a system where I can replicate the problem.

  -Ken

=== lib/Module/Build/Base.pm
==================================================================
--- lib/Module/Build/Base.pm	(revision 1998)
+++ lib/Module/Build/Base.pm	(local)
 <at>  <at>  -3971,11 +3971,11  <at>  <at> 
   my ($self,  <at> cmd) =  <at> _;
   $self->log_info(" <at> cmd\n");

-#  my %seen;
-#  my $sep = ref($self) ? $self->config('path_sep') : $Config{path_sep};
-#  local $ENV{PERL5LIB} = join $sep, grep {
-#    ! $seen{$_}++ and -d $_
-#  } split($sep, $ENV{PERL5LIB});
+  my %seen;
+  my $sep = ref($self) ? $self->config('path_sep') : $Config{path_sep};
+  local $ENV{PERL5LIB} = join $sep, grep {
+    ! $seen{$_}++ and -d $_
+  } split($sep, $ENV{PERL5LIB});

Re: Irony? Module::Build cannot itself be built.

# from Ken Williams
# on Monday 11 September 2006 07:38 pm:

>Is it the right solution?  Beats me.  I still haven't gotten my hands
>   on a system where I can replicate the problem.

Let's see, we worked-around the inflated argument list by removing  <at> INC 
directories that don't exist and then it fails a test on adding a 
directory that doesn't exist to  <at> INC.

  plan skip_all => '...' if(-e '/etc/redhat-release');

(or maybe check `perl --version` for something indicative?)

Seriously, just skip anything that causes the least bit of trouble and 
print a big warning about peRHl being of questionable compatibility.  
At least then it will function in most cases and whoever finds the 
weird bits can send patches or bug their vendor.

# from David Bogen on Monday 11 September 2006 10:46 am:

>Have I missed something?  Is there a definitive method for getting
>Module::Build to, well, build on RedHat's Enterprise Linux?

AFAICT, the conclusion was "install perl".

--Eric
--

-- 
"Unthinking respect for authority is the greatest enemy of truth."
--Albert Einstein

Re: Installing Tests

----- Original Message ----
From: Ken Williams

> Yes, I've been thinking about this for a long time.  In fact, in the
> most recent M::B beta I made some steps toward it, by adding a
> 'retest' action that's just like 'test' except that it doesn't look
> in blib/, just in  <at> INC.  Functionally that actually covers a lot of
> the same ground you're after.

Sweet!

>   4) Many distributions, including many of the most crucial and well-
> used ones, have some extra set-up steps in their build/install
> sequences.  Others make assumptions in their test suites about where
> various files are located relative to the test code or relative to
> the current working directory.  It's quite possible that in order for
> "installed" tests to work correctly it could take some serious
> coöperation by modules' authors.

In that case, ./Build install could be this (or something similar):

  ./Build install --with-tests 

Then, after the module is installed, the installed tests are run against the installed version and if
there's a failure, the user could be given the option to uninstall them.

>   5) Where should tests be installed?  Where would any other
> supporting materials be installed?

Don't ask me :)

Re: Irony? Module::Build cannot itself be built.

Eric Wilhelm wrote:
> Seriously, just skip anything that causes the least bit of trouble and 
> print a big warning about peRHl being of questionable compatibility.  

Just FYI, it's not that RHE is incompatible; it is *too* compatible.  The reason
for the huge  <at> INC list is that RedHat decided to upgrade Perl itself over the
course of multiple releases of RedHat.  They did this by including all previous
binary-compatible directory trees into each release (e.g. 5.8.8 also includes
the full core and site paths for 5.8.7, 5.8.6, etc).  This means they could
install a newer version of Perl without requiring all previously installed
modules to be reinstalled.  On the other hand, when *I* upgrade Perl beyond what
my distro provides, I move all of the site_perl stuff into the newer tree
manually, not something a distro would want to do.

I think the only sane solution to this problem is to find some way to stop
relying on shell expansion, which is the only place this is a problem.  Perl
itself has no problem with multiple locations in  <at> INC, even if only some of them
exist on disk.

John

--

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