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

Re: [Module::Build] Recursive builds?

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

# from David Golden
# on Saturday 11 February 2006 06:14 am:

>It would seem fairly trivial to add a "recurse_into" parameter with
>directories but then what?

chdir into each one and run $perl, 'Build.PL' or $perl, 'Build' with the=20
same arguments.

>Are each of the directories mirrors of a=20
>normal distribution with their own lib and t directories?

I'm pretty sure that's roughly what ExtUtils::MakeMaker does.

>And how=20
>should building/testing/installing work? =A0Copy all relevant files from
>all recursive directories into a top level blib directory?

No.  I think the primary need for recursive builds is to be able to put=20
multiple distributions together and/or separate the Build.PL files to=20
keep things sane.  I would also like to be able to trigger MakeMaker=20
builds (unless Module::Build::Inline would be trivial.)  I suppose=20
handling the differences between what arguments are supported by=20
MakeMaker makes this hairy.

>Or should there be blibs in each directory?

Yes.  You should be able to chdir into each one and run build as if it=20
were a standalone distribution.

>Should top level tests assume the=20
>existence of (and know how to find) files from lower down in the tree?

No.  Maybe.  If so, it should just add every blib/ to @INC.  I imagine=20
that the toplevel tests might be used to test integration of the=20
recursively built modules?

=2D-Eric
=2D-=20
Speak softly and carry a big carrot.
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [Module::Build] Recursive builds?

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

Eric Wilhelm wrote:
> # from Ken Williams
> # on Friday 10 February 2006 05:50 pm:
> 
>> Are there any examples around for
>>
>>> using M::B for recursive builds, where you have a directory tree and
>>> each directory has its own Build.PL?  Seems like someone must have
>>> done that already, but darned if I can find it.
>> It also sounds not-too-difficult to me, but I don't actually know of
>> anyone that's done it either.  Anyone?
> 
> Ken, Is this your Friday night humor or did I miss something?  I was 
> thinking this was in the todo/not-quite-possible-yet category.
> 
> I'm also interested in getting recursive builds working, but my last 
> patch ended up in purgatory so I haven't looked into it.

My initial thought was that it seemed easy, but then my next thought was 
that a lot of M::B assumes certain semantics about the layout of a 
distribution (e.g. lib, t, META.yml, etc.)  that aren't so easy to 
generalize to a recursive case.

It would seem fairly trivial to add a "recurse_into" parameter with 
directories but then what?  Are each of the directories mirrors of a 
normal distribution with their own lib and t directories?  And how 
should building/testing/installing work?  Copy all relevant files from 
all recursive directories into a top level blib directory?  Or should 
there be blibs in each directory?  Should top level tests assume the 
existence of (and know how to find) files from lower down in the tree?

Maybe this is an in-joke or todo from years ago -- but has anyone 
actually drafted a spec for how this should work?

Regards,
David

Re: [Module::Build] Recursive builds?

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

# from Ken Williams
# on Friday 10 February 2006 05:50 pm:

>Are there any examples around for
>
>> using M::B for recursive builds, where you have a directory tree and
>> each directory has its own Build.PL? =A0Seems like someone must have
>> done that already, but darned if I can find it.
>
>It also sounds not-too-difficult to me, but I don't actually know of
>anyone that's done it either. =A0Anyone?

Ken, Is this your Friday night humor or did I miss something?  I was=20
thinking this was in the todo/not-quite-possible-yet category.

I'm also interested in getting recursive builds working, but my last=20
patch ended up in purgatory so I haven't looked into it.

=2D-Eric
=2D-=20
I arise in the morning torn between a desire to improve the world and a
desire to enjoy the world. This makes it hard to plan the day.
=2D-E.B. White
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [Module::Build] Recursive builds?

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

On Feb 10, 2006, at 10:47 AM, Peter Scott wrote:

> Hi there.  This sounds like a FAQ, but I have searched high and low 
> and not found it answered anywhere.  Are there any examples around for 
> using M::B for recursive builds, where you have a directory tree and 
> each directory has its own Build.PL?  Seems like someone must have 
> done that already, but darned if I can find it.

It also sounds not-too-difficult to me, but I don't actually know of 
anyone that's done it either.  Anyone?

  -Ken

[Module::Build] Recursive builds?

[Peter S. <Pe...@PS...>]

Hi there.  This sounds like a FAQ, but I have searched high and low and 
not found it answered anywhere.  Are there any examples around for 
using M::B for recursive builds, where you have a directory tree and 
each directory has its own Build.PL?  Seems like someone must have done 
that already, but darned if I can find it.
-- 
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com/
http://www.perlmedic.com/

[Module::Build] Re: Tie::CPHash prereq for Module::Build? (was: Module::Build status on VMS)

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

On Feb 5, 2006, at 10:18 PM, Yitzchak Scott-Thoennes wrote:

> Ken, do you have any problem with bundling Tie::CPHash in
> Module::Build under t/bundled?  The .pm file is just 5k.
> Alternatively, it could be a build prerequisite, but I'm guessing
> you'd rather not do that.

Sure, bundling in t/bundled would be just fine with me.  The bigger 
question is whether it goes in core, of course.

  -Ken

Re: [Module::Build] [Fwd: CPAN Upload: J/JP/JPEACOCK/version-AlphaBeta-0.06.tar.gz]

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

On Mon, 06 Feb 2006 06:14:39 -0500, John Peacock wrote:

Hi John

> Sadly, no that won't completely work yet.  I was mostly setting the
> ground work for eventual support.

Aka The Story of Our Lives...

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

Re: [Module::Build] [Fwd: CPAN Upload: J/JP/JPEACOCK/version-AlphaBeta-0.06.tar.gz]

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

Ron Savage wrote:
> On Sun, 05 Feb 2006 11:10:51 -0500, John Peacock wrote:
> 
> Hi John
> 
>> version-AlphaBeta-0.06.tar.gz
> 
> Now I'm wondering who will invoke this code.
> 
> For instance, will Module::Build look to see if this module - and 'version' - 
> are installed, and load them both, so as to call methods in 'version-AlphaBeta'?

Sadly, no that won't completely work yet.  I was mostly setting the ground work
for eventual support.

The problem is that Module::Build (and the PAUSE indexer, and of course EU::MM)
try to be cute with the $VERSION assignment, so they don't always react well
when something different than a straight assignment is there.  Presumably, as
soon as 0.27_08 is released, Module::Build will use the numify() method by
default, so this line:

	use version::AlphaBeta; $VERSION = version::AlphaBeta->new("0.1a");

will display (for Module::Build purposes) as:

	Creating new 'Build' script for 'Foo-Version' version '0.099997'

which will "work" but won't be what we want (in general).  I'm not sure how to
solve this in general (apart from providing a Module::Build::version class,
which handles this much better and DTRT more often).

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

[Module::Build] Re: Binary distributions

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

On 2/5/06, Offer Kaye <off...@gm...> wrote:
> BTW Gozer have you looked at the first line:
> Cannot forceunlink D:\cpanrun\build\5-8-0\lib\auto\List\Util\Util.dll:
> Permission denied at D:\cpanrun\build\5-8-0\lib/File/Find.pm line 874
>
> Maybe the script is trying to delete a file that the system thinks is
> in use? Or something similiar? Windows has that annoying habit of
> refusing to delete things it thinks are in use...

This is a known issue on Win32 that the MakeMaker people and the
Module Build people are aware of.

I've produced a patch for the install behaviour and I'm planning to
put together a patch for the uninstall behaviour Real Soon Now. Ive
also volunteered to maintain a new distro which would be split out of
the MakeMaker distro so that people can upgrade the install behaviour
without upgrading the whole MakeMaker package.

Randy Sims put together an initial version of this package including
the install patch at

   <http://thepierianspring.org/perl/ExtUtils-Install-1.35.tar.gz>

Cheers,
Yves




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

[Module::Build] Tie::CPHash prereq for Module::Build? (was: Module::Build status on VMS)

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

On Sun, Feb 05, 2006 at 06:10:58PM -0600, Craig A. Berry wrote:
> At 3:39 PM -0800 2/5/06, Yitzchak Scott-Thoennes wrote:
> 
> >Any progress on this front?  Given that this is just for purposes of
> >running tests, maybe here the hash keys should always be lowercased?
> >
> >The previous patch to add Module::Build no longer applies cleanly;
> >
> >http://zipcon.net/~sthoenna/mbaddfull270701.patch
> >
> >is updated to match bleadperl and what's currently in cvs for MB.
> 
> I'll try to look at that again soon -- too many projects in progress
> at once.   I did some hacking with Tie:CPHash from CPAN and got a bit
> farther.  A still not fully working diff of DistGen.pm is at the end
> of this message.

> --- DistGen.pm;2        Thu Jan 26 18:48:29 2006
> +++ DistGen.pm  Sun Jan 29 15:58:55 2006

> +use Tie::CPHash;
>  
>  sub new {
>    my $package = shift;
> @@ -29,6 +30,10 @@
>    );
>    my $self = bless( \%data, $package );
>  
> +  tie %{$self->{filedata}}, 'Tie::CPHash';
> +
> +  tie %{$self->{pending}{change}}, 'Tie::CPHash';


Ken, do you have any problem with bundling Tie::CPHash in
Module::Build under t/bundled?  The .pm file is just 5k.
Alternatively, it could be a build prerequisite, but I'm guessing
you'd rather not do that.

Rafael, what do you think about adding it to the core along with
Module-Build?  If the Module::Build tests need it, it would need to be
included in the perl source, but wouldn't necessarily have to get
installed.  But if Craig or someone else ends up modifying
ExtUtils::Manifest::manifind to rely on it at some point in the not
too distant future, it might make sense just to add it already.

A short review: the module looks pretty clean and simple; it does one
thing and does it with no frills.  It could stand to have a SCALAR
method added, but other than that the 8 year old code looks great.

Re: [Module::Build] Re: Module::Build status on VMS

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

At 3:39 PM -0800 2/5/06, Yitzchak Scott-Thoennes wrote:

>Any progress on this front?  Given that this is just for purposes of
>running tests, maybe here the hash keys should always be lowercased?
>
>The previous patch to add Module::Build no longer applies cleanly;
>
>http://zipcon.net/~sthoenna/mbaddfull270701.patch
>
>is updated to match bleadperl and what's currently in cvs for MB.

I'll try to look at that again soon -- too many projects in progress
at once.   I did some hacking with Tie:CPHash from CPAN and got a bit
farther.  A still not fully working diff of DistGen.pm is at the end
of this message.  I'm now getting, for example:

$ perl -"I[-.lib]" [-.lib.module.build.t]tilde.t
1..11
Warning: Removing existing directory 'D0:[CRAIG.perl.t._tmp.Simple]'
Changed file 't/basic.t'.
Changed file 'lib/Simple.pm'.
Changed file 'Build.PL'.
Splitting '[]'
Setting directory name '[]' in %names
Splitting '[.t]'
Setting directory name '[.t]' in %names
Setting directory name '[.t]' in %names
Splitting '[.lib]'
Setting directory name '[.lib]' in %names
Setting directory name '[.lib]' in %names
Splitting '[]'
Setting directory name '[]' in %names
Removing 'lib'
Removing 't'
Can't call method "install_base" on an undefined value at [-.lib.module.build.t]tilde.t line 44.
# No tests run!

I think the next hurdle is that File::Find is returning directory
names with no attached distinguishing punctuation (C<lib> or C<t>)
but the names that we've cached do have that punctuation (C<[.lib]>
or C<[.t]>).  File::Spec->canonpath does not normalize that:

$ perl -"MFile::Spec" -e "print File::Spec->canonpath('[.lib]');"
[.lib]
$ perl -"MFile::Spec" -e "print File::Spec->canonpath('lib');"
lib

So on VMS we'll have to get more aggressive about caching directory
names in the same form that we'll be looking them up.  Otherwise we
don't recognize directories that we want to keep and we end up
deleting before they are even used.

--- DistGen.pm;2        Thu Jan 26 18:48:29 2006
+++ DistGen.pm  Sun Jan 29 15:58:55 2006
@@ -5,7 +5,7 @@
 use vars qw( $VERSION $VERBOSE );
 
 $VERSION = '0.01';
-$VERBOSE = 0;
+$VERBOSE = 1;
 
 
 use Cwd ();
@@ -14,6 +14,7 @@
 use File::Path ();
 use File::Spec ();
 use IO::File ();
+use Tie::CPHash;
 
 sub new {
   my $package = shift;
@@ -29,6 +30,10 @@
   );
   my $self = bless( \%data, $package );
 
+  tie %{$self->{filedata}}, 'Tie::CPHash';
+
+  tie %{$self->{pending}{change}}, 'Tie::CPHash';
+
   if ( -d $self->dirname ) {
     warn "Warning: Removing existing directory '@{[$self->dirname]}'\n";
     $self->remove;
@@ -280,6 +285,7 @@
   }
 
   my %names;
+  tie %names, 'Tie::CPHash';
   foreach my $file ( keys %{$self->{filedata}} ) {
     my $filename = $self->_real_filename( $file );
     my ($vol, $dirname, $f) = File::Spec->splitpath( $filename );
@@ -288,10 +294,16 @@
 
     $names{$filename} = 0;
 
+    print "Splitting '$dirname'\n" if $VERBOSE;
     my @dirs = File::Spec->splitdir( $dirname );
     while ( @dirs ) {
-      my $dir = File::Spec->catdir( @dirs );
-      $names{$dir} = 0;
+      my $dir = ( scalar(@dirs) == 1
+                  ? $dirname
+                  : File::Spec->catdir( @dirs ) );
+      if (length $dir) {
+        print "Setting directory name '$dir' in \%names\n" if $VERBOSE;
+        $names{$dir} = 0;
+      }
       pop( @dirs );
     }
   }
@@ -299,11 +311,13 @@
   File::Find::finddepth( sub {
     my $name = File::Spec->canonpath( $File::Find::name );
 
+    $name =~ s/\.\z// if $^O eq 'VMS';
+
     if ( not exists $names{$name} ) {
       print "Removing '$name'\n" if $VERBOSE;
       File::Path::rmtree( $_ );
     }
-  }, File::Spec->curdir );
+  }, './' );

   chdir( $here );
 }


-- 
________________________________________
Craig A. Berry
mailto:cra...@ma...

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Re: [Module::Build] [Fwd: CPAN Upload: J/JP/JPEACOCK/version-AlphaBeta-0.06.tar.gz]

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

On Sun, 05 Feb 2006 11:10:51 -0500, John Peacock wrote:

Hi John

> version-AlphaBeta-0.06.tar.gz

Now I'm wondering who will invoke this code.

For instance, will Module::Build look to see if this module - and 'version'=
 - 
are installed, and load them both, so as to call methods in=
 'version-AlphaBeta'?

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

Re: [Module::Build] Re: Module::Build status on VMS

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

On Thu, Jan 26, 2006 at 10:41:55PM -0600, Craig A. Berry wrote:
> At 9:31 PM -0500 1/26/06, John E. Malmberg wrote:
> >Craig A. Berry wrote:
> >>
> >>So now we're getting to the problem that was Yitzchak's first theory,
> >>namely that it's a case problem, more specifically, the case-leveled
> >>names returned from File::Find do not match the case-preserved names
> >>in the hash, so we delete the files because they are not recognized.
> >>One way to deal with this would be to acquire or build a
> >>case-tolerant tied hash and use one of those instead of an ordinary
> >>hash.  Basically when you look up a case-preserved name in the hash
> >>and it doesn't match, it will then look up a case-leveled version for
> >>you.  Schwern suggested this solution a long time ago for
> >>ExtUtils::Manifest::manifind() and it's still needed there, so
> >>perhaps we could put such a package in a place where both MM and MB
> >>can use it.  I think there are a couple of implementations on CPAN .

Any progress on this front?  Given that this is just for purposes of
running tests, maybe here the hash keys should always be lowercased?

The previous patch to add Module::Build no longer applies cleanly;

http://zipcon.net/~sthoenna/mbaddfull270701.patch

is updated to match bleadperl and what's currently in cvs for MB.

Re: [Module::Build] [Fwd: CPAN Upload: J/JP/JPEACOCK/version-AlphaBeta-0.06.tar.gz]

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

On Sun, 05 Feb 2006 11:10:51 -0500, John Peacock wrote:

Hi John

> In relation to the recent discussion of how to compare version-like
> objects using numify(), I have updated my version::AlphaBeta class
> to support that method too.  This class allows you to have version
> objects like 1.3b...

$many x $thanx for your contribution.

Since I saw (in my email client) about 3 msgs on this topic, I checked the=
 mail 
archives, and now see - to my horror - 19, so somewhere along the line I'm=
 not 
receiving msgs. My internet connexion has been curiously slow over the last=
 few 
days, so I'm hoping the loss of msgs is a transient and now historical=
 problem.

I say this by way of explanation to any of you who may have been expecting=
 me to 
say something during the discussion. Sorry, even though I'm hopeful it's 
ENOTMYFAULTEITHER.
-- 
Cheers
Ron Savage, ro...@sa... on 6/02/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

[Module::Build] [Fwd: CPAN Upload: J/JP/JPEACOCK/version-AlphaBeta-0.06.tar.gz]

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

In relation to the recent discussion of how to compare version-like objects
using numify(), I have updated my version::AlphaBeta class to support that
method too.  This class allows you to have version objects like 1.3b...

========================================================
The uploaded file

    version-AlphaBeta-0.06.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/J/JP/JPEACOCK/version-AlphaBeta-0.06.tar.gz
  size: 12617 bytes
   md5: 19b637933bf5991ef15ccf2777f5fa20
========================================================

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Re: [Module::Build] proposed patch for "testauthor" action

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

Yitzchak Scott-Thoennes wrote:
>> It provides a "testauthor" action that sets $ENV{AUTHOR_TESTING} to 1 
>> before running the "test" action.
> 
> I would also suggest setting it in ACTION_disttest.

Isn't disttest supposed to mimic what would happen if someone downloaded 
the distribution and ran the tests?  From that perspective, I'm not sure 
that it should run in that situation.

>> The name of the action follows the pattern set by "testdb", "testpod", 
>> "testcover", etc.  The environment variable follows the pattern of 
>> "AUTOMATED_TESTING" used by the CPAN smoke tests.
> 
> Despite the AUTOMATED_TESTING precedent, I'd prefer to see
> a PERL_ prefix on the environment variable.

I thought about that and would be supportive of it if a consensus 
emerged.  (I figured putting out a patch would force a decision.)

>> +=item testauthor
>> +
>> +This is a synonym for the C<test> action with the environment variable
>> +C<AUTHOR_TESTING> set to 1.  Test files that are only of interest to module
>> +authors during development choose to skip running if the environment variable
>> +is not set.  E.g.
> 
> That reads a little awkwardly.  Did you mean "may choose"?

Yes.  Thank you for catching that.  I kept rewording that tortured 
sentence between a recommendation and an option.  Somewhere in there, 
the "may" went away.

Regards,
David

Re: [Module::Build] proposed patch for "testauthor" action

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

On Sat, Feb 04, 2006 at 05:06:22PM -0500, David Golden wrote:
> Following the notion that actions speak louder than words, I offer the 
> attached patch against the current CVS head.  (Including test file and 
> documentation.)
> 
> It provides a "testauthor" action that sets $ENV{AUTHOR_TESTING} to 1 
> before running the "test" action.

I would also suggest setting it in ACTION_disttest.
 
> The name of the action follows the pattern set by "testdb", "testpod", 
> "testcover", etc.  The environment variable follows the pattern of 
> "AUTOMATED_TESTING" used by the CPAN smoke tests.

Despite the AUTOMATED_TESTING precedent, I'd prefer to see
a PERL_ prefix on the environment variable.

> +=item testauthor
> +
> +This is a synonym for the C<test> action with the environment variable
> +C<AUTHOR_TESTING> set to 1.  Test files that are only of interest to module
> +authors during development choose to skip running if the environment variable
> +is not set.  E.g.

That reads a little awkwardly.  Did you mean "may choose"?

Re: [Module::Build] proposed patch for "testauthor" action

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

Chris Dolan wrote:
> I'm very happy with this patch.  I believe that someone (Ken?) raised 
> the objection that envvars were troublesome on some platforms.  I'm 
> curious to learn more about that objection.  Nonetheless, I posit that 
> author tests are a fringe feature and, at the risk of being platformist, 
> I think it's OK if it doesn't work absolutely everywhere.  And given 
> that other test actions have set a precedent, I think we're OK with this 

I can't speak to multiple platforms beyond Linux and Windows, so I'm 
curious to know any specifics from those who have experienced problems 
with portability.  Reading "perldoc perlport", there's some caveats 
about %ENV, but it has more to do with expecting certain things to be in 
it (e.g. TZ) or to mean the same thing on different platforms.  (There's 
a case sensitivity caveat that's a little concerning -- but it's a 
vague, general statement.)

At the very least, M::B uses environment variables in several other 
places to communicate with sub-processes, so I'm hoping something this 
simple is fairly robust.

David

Re: [Module::Build] proposed patch for "testauthor" action

[Chris D. <ch...@cl...>]

I'm very happy with this patch.  I believe that someone (Ken?) raised  
the objection that envvars were troublesome on some platforms.  I'm  
curious to learn more about that objection.  Nonetheless, I posit  
that author tests are a fringe feature and, at the risk of being  
platformist, I think it's OK if it doesn't work absolutely  
everywhere.  And given that other test actions have set a precedent,  
I think we're OK with this approach.

Chris

On Feb 4, 2006, at 4:06 PM, David Golden wrote:

> Following the notion that actions speak louder than words, I offer  
> the attached patch against the current CVS head.  (Including test  
> file and documentation.)
>
> It provides a "testauthor" action that sets $ENV{AUTHOR_TESTING} to  
> 1 before running the "test" action.
>
> The name of the action follows the pattern set by "testdb",  
> "testpod", "testcover", etc.  The environment variable follows the  
> pattern of "AUTOMATED_TESTING" used by the CPAN smoke tests.
>
> The functionality itself took less than 60 seconds to write.  The  
> longest part was figuring out how to write a test for it.  (0.29  
> wishlist: more test refactoring.)
>
> Regards,
> David
> === t/testauthor.t
> ==================================================================
> --- t/testauthor.t	(revision 3287)
> +++ t/testauthor.t	(patch author_testing level 1)
> @@ -0,0 +1,67 @@
> +#!/usr/bin/perl -w
> +
> +use strict;
> +use lib $ENV{PERL_CORE} ? '../lib/Module/Build/t/lib' : 't/lib';
> +use MBTest tests => 7;
> +
> +use Cwd ();
> +my $cwd = Cwd::cwd;
> +my $tmp = File::Spec->catdir( $cwd, 't', '_tmp' );
> +
> +use DistGen;
> +
> +#########################
> +
> +use DistGen;
> +my $dist = DistGen->new( dir => $tmp );
> +$dist->change_file( 't/basic.t', <<'---');
> +use Test::More;
> +plan tests => 1;
> +is( $ENV{AUTHOR_TESTING}, '1', '$ENV{AUTHOR_TESTING} set');
> +---
> +
> +$dist->regen;
> +
> +chdir( $dist->dirname ) or die "Can't chdir to '@{[$dist- 
> >dirname]}': $!";
> +
> +#########################
> +
> +use Module::Build;
> +ok(1);
> +
> +SKIP: {
> +  skip "no blib in core", 1 if $ENV{PERL_CORE};
> +  like $INC{'Module/Build.pm'}, qr/\bblib\b/, "Make sure version  
> from blib/ is loaded";
> +}
> +
> +#########################
> +
> +my $mb = Module::Build->new_from_context;
> +ok $mb;
> +
> +eval {$mb->create_build_script};
> +is $@, '';
> +ok -e $mb->build_script;
> +
> +{
> +  # Make sure verbose=>1 works
> +  my $all_ok = 1;
> +  my $output = eval {
> +    stdout_of( sub { $mb->dispatch('testauthor', verbose => 1) } )
> +  };
> +  $all_ok &&= is($@, '');
> +  $all_ok &&= like($output, qr/all tests successful/i);
> +
> +  unless ($all_ok) {
> +    # We use diag() so Test::Harness doesn't get confused.
> +    diag("vvvvvvvvvvvvvvvvvvvvv Simple/test.pl output  
> vvvvvvvvvvvvvvvvvvvvv");
> +    diag($output);
> +    diag("^^^^^^^^^^^^^^^^^^^^^ Simple/test.pl output  
> ^^^^^^^^^^^^^^^^^^^^^");
> +  }
> +}
> +
> +# cleanup
> +$dist->remove;
> +
> +use File::Path;
> +rmtree( $tmp );
>
> === lib/Module/Build/Base.pm
> ==================================================================
> --- lib/Module/Build/Base.pm	(revision 3287)
> +++ lib/Module/Build/Base.pm	(patch author_testing level 1)
> @@ -1882,6 +1882,14 @@
>    $self->depends_on('test');
>  }
>
> +sub ACTION_testauthor {
> +  my ($self) = @_;
> +
> +  local $ENV{AUTHOR_TESTING} = 1;
> +
> +  $self->depends_on('test');
> +}
> +
>  sub ACTION_testcover {
>    my ($self) = @_;
>
> === lib/Module/Build.pm
> ==================================================================
> --- lib/Module/Build.pm	(revision 3287)
> +++ lib/Module/Build.pm	(patch author_testing level 1)
> @@ -490,6 +490,19 @@
>
>    ./Build test --test_files 't/01-*.t'
>
> +=item testauthor
> +
> +This is a synonym for the C<test> action with the environment  
> variable
> +C<AUTHOR_TESTING> set to 1.  Test files that are only of interest  
> to module
> +authors during development choose to skip running if the  
> environment variable
> +is not set.  E.g.
> +
> +  use Test::More;
> +  plan skip_all "Author test" if not $ENV{AUTHOR_TESTING};
> +
> +  plan tests => 42;
> +  # test file continues
> +
>  =item testcover
>
>  Runs the C<test> action using C<Devel::Cover>, generating a

-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

[Module::Build] proposed patch for "testauthor" action

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

Following the notion that actions speak louder than words, I offer the 
attached patch against the current CVS head.  (Including test file and 
documentation.)

It provides a "testauthor" action that sets $ENV{AUTHOR_TESTING} to 1 
before running the "test" action.

The name of the action follows the pattern set by "testdb", "testpod", 
"testcover", etc.  The environment variable follows the pattern of 
"AUTOMATED_TESTING" used by the CPAN smoke tests.

The functionality itself took less than 60 seconds to write.  The 
longest part was figuring out how to write a test for it.  (0.29 
wishlist: more test refactoring.)

Regards,
David

Re: [Module::Build] [RFC] author tests

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

On Fri, 3 Feb 2006 15:35:42 -0800, Austin Schutz wrote:

Hi Austin

> Dumb question: can't you just $ENV{'FOO'}=3D ... before you run the
> tests?

You mean from the command line? Sure. But why should I be /forced/ to use=
 the 
command line?
-- 
Cheers
Ron Savage, ro...@sa... on 4/02/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

[Module::Build] Re: Modules Still for Sale? (was: replacing "inuse" Win files)

[Randy K. <ra...@th...>]

On Fri, 3 Feb 2006, Randy W. Sims wrote:

> Ken Williams wrote:
>> 
>> On Feb 3, 2006, at 3:04 AM, demerphq wrote:
>> 
>>> If needed Ill volunteer take over maintenance of this (my cpan id is
>>> YVES) with Max (cpanid:CORION) as co-maintainer on the *nixy side.
>>> I've cc'ed him on this mail. We'd be happy if other maintainers were
>>> added I should think, especially if they were handling VMS. :-)
>> 
>> There was also someone else who stepped forward at some point (or maybe 
>> everyone else stepped back) to take it over a few months ago, but I guess 
>> it hasn't happened and I'll be danged if I can't remember who it was. 
>> Schwern, you remember?
>
> I think Randy Kobes volunteered to take over some of the "Modules For 
> Sale"[1], but I don't recall which ones; and, to the best of my knowledge, no 
> one has pried any of them out of Schwern's hands yet. ;)

I volunteered for ExtUtils-Command and ExtUtils-Manifest,
both of which are in http://svn.perl.org/modules/.
They can't be released yet to CPAN without coordination
from ExtUtils-MakeMaker.

-- 
best regards,
Randy

[Module::Build] Modules Still for Sale? (was: replacing "inuse" Win files)

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

Ken Williams wrote:
> 
> On Feb 3, 2006, at 3:04 AM, demerphq wrote:
> 
>> If needed Ill volunteer take over maintenance of this (my cpan id is
>> YVES) with Max (cpanid:CORION) as co-maintainer on the *nixy side.
>> I've cc'ed him on this mail. We'd be happy if other maintainers were
>> added I should think, especially if they were handling VMS. :-)
> 
> There was also someone else who stepped forward at some point (or maybe 
> everyone else stepped back) to take it over a few months ago, but I 
> guess it hasn't happened and I'll be danged if I can't remember who it 
> was.  Schwern, you remember?

I think Randy Kobes volunteered to take over some of the "Modules For 
Sale"[1], but I don't recall which ones; and, to the best of my 
knowledge, no one has pried any of them out of Schwern's hands yet. ;)

Actually, Schwern made a reasonable request that someone show commitment 
to maintaining them first[1]. For example, knocking of something related 
in RT[2].

Either/Both Randy or Yves would make good maintainers, and I'll help 
where I can (I'm too unpredictable and irresponsible to maintain =). 
I've put together a couple of these modules in a dist[3], and I'll try 
to help put together a "non-trivial patch" to help pry them loose...

Randy.


1. <http://makemaker.org/wiki/index.cgi?ModulesForSale>
2. <http://rt.cpan.org/NoAuth/Bugs.html?Dist=ExtUtils-MakeMaker>
3. <http://thepierianspring.org/perl/ExtUtils-Install-1.35.tar.gz>

Re: [Module::Build] [RFC] author tests

[Austin S. <te...@of...>]

On Fri, Feb 03, 2006 at 04:58:28PM +1100, Ron Savage wrote:
> On Thu, 2 Feb 2006 21:47:21 -0600, Ken Williams wrote:
> 
> Hi Ken
> 
> > In general I like the idea.  In specific I don't like the idea of
> > using an environment variable.  Could we use some parameter or
> > command-line argument or something like that instead?  Environment
> > variables aren't completely portable and they're about as global as
> > one can get, so usually I've tried to avoid using them in M::B.
> 
> The killer for an env var is that I for one install modules via a cgi script on
> machines where I do /not/ have access to httpd.conf, so I can't ever use
> Perl(Set)Env to pass personal env vars thru to my scripts.
> 

	Dumb question: can't you just $ENV{'FOO'}= ... before you run the
tests?
	I have many scripts which call config files upon startup to set
environment variables and the like.
	You wouldn't be able to run the tests directly, but I'm not sure
that's relevant.

	Austin

Re: [Module::Build] [RFC] author tests

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

On Fri, 03 Feb 2006 07:01:33 -0500, David Golden wrote:

Hi David

> But do you need to run all the author tests, then?

No, that's true.

There are other issues like: Some modules have tests which fail, but I still=
 go 
ahead and install and use the modules anyway. Where does this all end?
-- 
Cheers
Ron Savage, ro...@sa... on 4/02/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company