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

[Module::Build] Re: Rejecting uploads without (an appropriate) license?

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

Adam Kennedy wrote:
> There's a few classes of checks we can do.
> 
> If the package has a META.yml, it should have a license field. There are 
> about a dozen legitimate values.
> 
> license 'restrictive'
> 
> The is an absolute positive match for a disallowed license.
> 
> A check covering the above case could safely be added immediately.
> 
> Beyond that you have three additional cases...
> 
> - The license value exists but is not a known type
> 
> - There is no license value in the META.yml
> 
> - There is no META.yml

There is a snapshot of how the license field in META.yml is used at:

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

     1 GPL             # wrong case
     4 GPL version 2   # invalid value
     3 GPLv2           # invalid value
     3 INVALID         # These have a url as a value
     1 LGPL            # wrong case
  3619 NONE            # No license field
     1 Perl            # wrong case
    50 artistic
    26 bsd
    61 gpl
     6 lgpl
    10 open_source
  1497 perl
     2 restrictive
    26 unknown         # invalid value: literal 'unknown'
     3 unrestricted

There should probably be a gpl2 & gpl3. Do we care about case?

Randy.

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

On Feb 17, 2006, at 8:01 AM, Nicholas Clark wrote:

> It won't hurt them, but it will cause immense pain for anyone  
> wanting to
> ship a module that uses a Build.PL - those developers will be  
> forced to
> decide whether to cut out anyone with an old Module::Build, or code  
> their
> Build.PL to use that version and work around the deficiencies.

Those authors should just be able to put a 'build_requires'  
dependency on the right version of Module::Build.


>
> The thread on what YAML version Module::Build needs, and how to  
> upgrade
> correctly if there isn't >=0.50 suggests that solving these  
> "Module::Build
> needs upgrading" issues isn't yet battle tested.

That's a different issue - the problem there is how to handle  
increases in 'feature' requirements, e.g. the 'yaml_support' feature  
for M::B.

  -Ken

Re: [Module::Build] M::B and version.pm

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

On Feb 22, 2006, at 2:54 PM, John Peacock wrote:

> If Ken and/or Randy want to tell me whether they want to hold 0.28  
> for the fully debugged and thought out version object support, I  
> will do what I can to get that working.

I'm quite happy to wait until after 0.28 to address it.

  -Ken

Re: [Module::Build] Re: META.yml feature for autotesters?

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

On Feb 24, 2006, at 11:42 PM, Tyler MacDonald wrote:

> Adam Kennedy <cp...@al...> wrote:
>> So while we are on the subject of META.yml, I think the  
>> dynamic_config
>> approach is horrible, because it defaults to an efficient error  
>> case and
>> relies on the author to fix the error, rather than defaulting to the
>> inefficient correct case, and giving the option to make it faster.
>>
>> Where would be the best place to get this flag changed (or for a
>> discussion on doing so) in the spec?

Weird, how did this discussion get into this thread?

In any case, I agree about dynamic_config.  It's actually documented  
oppositely in two different places, the latter of which is correct:

   http://search.cpan.org/~kwilliams/Module-Build-0.27_07/lib/Module/ 
Build/Authoring.pod
   http://module-build.sourceforge.net/META-spec- 
v1.2.html#dynamic_config

We'll need to change this in the M::B docs (there's nothing to do in  
the code), but my sense is that there's very little being done "in  
the wild" with this flag right now so I'd expect very little breakage  
with this doc change. =)

  -Ken

Re: [Module::Build] ./Build on Win98

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

On Feb 25, 2006, at 1:32 PM, Randy W. Sims wrote:

> Ok, here's the problem. The quoting is wrong in the invokation of
> pl2bat. Both arguments to pl2bat got bungled into one misformed  
> arg. I need to figure out how to invoke pl2bat from the command  
> line with corrected quoting. The command we're using now, that  
> produces the bungled last line above is:
>
> pl2bat -n "-x -S """%0""" --build_bat %*" -o "-x -S """%0""" -- 
> build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9" < Build > Build.bat
>
> It looks like it is trying to expand %*" -o "-x -S """% as an  
> evironment var. Maybe an extra space after %*:
>
> pl2bat -n "-x -S """%0""" --build_bat %* " -o "-x -S """%0""" -- 
> build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9 " < Build > Build.bat
>
> Otherwise, I'm not sure how to quote the percent symbol (%%*  
> doesn't work). I've posted a message over on alt.msdos.batch about  
> this.

Won't the multi-argument form of system() be helpful here?  It's  
generally much easier to get that to work out than trying to get  
quoting right.

  -Ken

Re: [Module::Build] ./Build on Win98

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

Dr Bean wrote:
> On Fri, 24 Feb 2006, Randy W. Sims wrote:
>>I'd like to know if the resulting 'Build.bat' differs on Win9x. I 
>>suspect not. Otherwise the invokation of perl from the batch file would 
>>cause errors or different behavior.
> 
> 
> @rem = '--*-Perl-*--
> @echo off
> if "%OS%" == "Windows_NT" goto WinNT
> perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
> goto endofperl
> :WinNT
> perl -x -S "%0" --build_bat 0" --build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9

Ok, here's the problem. The quoting is wrong in the invokation of
pl2bat. Both arguments to pl2bat got bungled into one misformed arg. I 
need to figure out how to invoke pl2bat from the command line with 
corrected quoting. The command we're using now, that produces the 
bungled last line above is:

pl2bat -n "-x -S """%0""" --build_bat %*" -o "-x -S """%0""" --build_bat 
%1 %2 %3 %4 %5 %6 %7 %8 %9" < Build > Build.bat

It looks like it is trying to expand %*" -o "-x -S """% as an evironment 
var. Maybe an extra space after %*:

pl2bat -n "-x -S """%0""" --build_bat %* " -o "-x -S """%0""" 
--build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9 " < Build > Build.bat

Otherwise, I'm not sure how to quote the percent symbol (%%* doesn't 
work). I've posted a message over on alt.msdos.batch about this.

Meanwhile, maybe the above command will produce a valid Build.bat file?

Randy.

Re: [Module::Build] add_build_element Should Add Only Once

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

On Feb 24, 2006, at 19:58, Randy W. Sims wrote:

> Anyhow, your patch seems like a good idea as a preventative, so  
> I've applied it.

Yeah, I don't understand it, either, but thanks for adding it!

David

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

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

On Feb 24, 2006, at 5:43 PM, Yitzchak Scott-Thoennes wrote:
> Just testing, and apparently really just for VMS, but I think it's
> be better to have all tests go through the same code, so have all
> platforms use it.

Okay, thanks, applied.  Did we ever figure out why the hard-coding  
was needed for that last line?  Is it File::Find being too Unix-centric?

  -Ken

Re: [Module::Build] ./Build on Win98

[Dr B. <gr...@mo...>]

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

> >D:\greg\Module-Build> Build realclean
> >Deleting _build
> >Deleting Build
> >Deleting Build.bat
> >Batch file missing

> It's taking the wrong path here. M::B is deleting 'Build.bat' where it 
> should be letting it delete itself. We know this method of self-deletion 
> works because it was proved in a previous attempt. The only issue here 
> is that the created 'Build.bat' is not correctly passing in the 
> --build_bat argument. To prove this you should be able to:

>   perl Build.PL
>   Build --build_bat realclean

D:\greg\Module-Build>Build --build_bat realclean
Deleting _build
Deleting Build

D:\greg\Module-Build>dir build

 Volume in drive D has no label
 Volume Serial Number is 4658-17D7
 Directory of D:\greg\Module-Build

BUILD    PL          2,591  02-02-06   8:19 Build.PL
         1 file(s)          2,591 bytes
         0 dir(s)       13,721.52 MB free

> and get a successful run without error about missing batch file.

OK.


> If you run:

>   perl Build.PL

> and then look at the top of the resulting 'Build.bat', you should see 
> the following lines:

> if "%OS%" == "Windows_NT" goto WinNT
> perl -x -S "%0" "--build_bat" %1 %2 %3 %4 %5 %6 %7 %8 %9
> goto endofperl
> :WinNT
> perl -x -S "%0" "--build_bat" %*

> I'd like to know if the resulting 'Build.bat' differs on Win9x. I 
> suspect not. Otherwise the invokation of perl from the batch file would 
> cause errors or different behavior.

@rem = '--*-Perl-*--
@echo off
if "%OS%" == "Windows_NT" goto WinNT
perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
goto endofperl
:WinNT
perl -x -S "%0" --build_bat 0" --build_bat %1 %2 %3 %4 %5 %6 %7 %8 %9
if NOT "%COMSPEC%" == "%SystemRoot%\system32\cmd.exe" goto endofperl
if %errorlevel% == 9009 echo You do not have Perl in your PATH.
if errorlevel 1 goto script_failed_so_exit_with_non_zero_val 2>nul
goto endofperl
@rem ';
#!perl
#line 15

They are not the same.

But if I substitute 
perl -x -S "%0" "--build_bat" %1 %2 %3 %4 %5 %6 %7 %8 %9
for the invocation line, Build realclean deletes Build.bat,

 Volume in drive D has no label
 Volume Serial Number is 4658-17D7
 Directory of D:\greg\Module-Build

BUILD    PL          2,591  02-02-06   8:19 Build.PL
BUILD                1,472  02-25-06  15:18 Build
BUILD    BAT         1,943  02-25-06  15:18 Build.bat
         3 file(s)          6,006 bytes
         0 dir(s)       13,721.28 MB free

D:\greg\Module-Build>Build realclean
Deleting _build
Deleting Build

D:\greg\Module-Build>dir build

 Volume in drive D has no label
 Volume Serial Number is 4658-17D7
 Directory of D:\greg\Module-Build

BUILD    PL          2,591  02-02-06   8:19 Build.PL
         1 file(s)          2,591 bytes
         0 dir(s)       13,721.52 MB free

D:\greg\Module-Build>

and Build --build_bat realclean does too.

D:\greg\Module-Build>Build --build_bat realclean
Deleting _build
Deleting Build

D:\greg\Module-Build>dir build

 Volume in drive D has no label
 Volume Serial Number is 4658-17D7
 Directory of D:\greg\Module-Build

BUILD    PL          2,591  02-02-06   8:19 Build.PL
         1 file(s)          2,591 bytes
         0 dir(s)       13,721.52 MB free

D:\greg\Module-Build>

> At one time those quotes around the --build_bat arg seemed necessary, 
> but it may be the cause of the problem; Although, I don't see why they 
> should matter one way or the other. I've removed those quotes, and 
> instrumented the code to see if I can find out where the argument is going.

> Care to give it another spin?

>   <http://thepierianspring.org/perl/Module-Build.tar.gz>


>   perl Build.PL
>   Build realclean
>   if exist Build.bat echo profanity

D:\greg\Module-Build>Build realclean
Deleting _build
Deleting Build
########################################
build_bat: 0
$VAR1 = 'ARGV';
$VAR2 = [];
########################################
Deleting Build.bat
Batch file missing

D:\greg\Module-Build>Build --build_bat realclean
Deleting _build
Deleting Build
########################################
build_bat: 1
$VAR1 = 'ARGV';
$VAR2 = [];
########################################

D:\greg\Module-Build>dir build

 Volume in drive D has no label
 Volume Serial Number is 4658-17D7
 Directory of D:\greg\Module-Build

BUILD    PL          2,591  02-02-06   8:19 Build.PL
         1 file(s)          2,591 bytes
         0 dir(s)       13,721.61 MB free

And with the same changes to the perl invocation args as above:

D:\greg\Module-Build>Build realclean
Deleting _build
Deleting Build
########################################
build_bat: 1
$VAR1 = 'ARGV';
$VAR2 = [];
########################################

D:\greg\Module-Build>dir build

 Volume in drive D has no label
 Volume Serial Number is 4658-17D7
 Directory of D:\greg\Module-Build

BUILD    PL          2,591  02-02-06   8:19 Build.PL
         1 file(s)          2,591 bytes
         0 dir(s)       13,721.61 MB free


And the same with Build --build_bat realclean

So it seems that the behavior is the same between the 2 versions.

--
Dr Bean

[Module::Build] Re: META.yml feature for autotesters?

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

Adam Kennedy <cp...@al...> wrote:
> So while we are on the subject of META.yml, I think the dynamic_config 
> approach is horrible, because it defaults to an efficient error case and 
> relies on the author to fix the error, rather than defaulting to the 
> inefficient correct case, and giving the option to make it faster.
> 
> Where would be the best place to get this flag changed (or for a 
> discussion on doing so) in the spec?

	The module-build project, maintained by Ken Williams, is currently
hosting the META.yml spec;

	http://module-build.sourceforge.net/

	I guess META.yml's "reccomends" feature accomplishes most of what
I'm after (if you can't install the module don't worry about it, but if you
can, it'll enhance things), but what I was looking for was a place to dump
stuff like that that doesn't affect the usability of the package, just the
testability. "build_recommends" was suggested on module-build-general, but
it appears to have disappeared from the Module::Build code and isn't on the
META.yml spec.

		- Tyler

Re: [Module::Build] add_build_element Should Add Only Once

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

David E.Wheeler wrote:
> Module::Builders,
> 
> Somehow, I've been finding in my tests that the same element keeps 
> getting added to my build objets over and over again. I don't know why, 
> but the fix is easy.
> 
> The attached patch modifies add_build_element() so that it only adds the 
> element if it doesn't already exist. Any reason *not* to do this?

I had a look. I don't see anywhere this might be happening within M::B. 
The build_elements property is touched very few times, almost 
exclusively for read-only access. The only place where it's modified is 
in the add_build_elements method and it is never called within M::B. If 
it is something in M::B causing the duplication, I'd like to find it, 
but I don't think it is from my quick look. Maybe something on your side?

Anyhow, your patch seems like a good idea as a preventative, so I've 
applied it.

Thanks,
Randy.

Re: [Module::Build] PL_Files and add_to_cleanup

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

John Peacock wrote:
> I was noticing that if I create some files using a .PL script that I 
> listed in the PL_FILES hash, that these files are not automatically 
> deleted when running './Build distclean' (or realclean or clean). 
> Shouldn't they be automatically added to the add_to_cleanup files?  I 
> cannot think of a use case where these files shouldn't be deleted (since 
> they are always overwritten by Build).
> 
> I can produce a patch if that would be acceptable.


I peeked at the code; it looks like it should work correctly:

sub process_PL_files {
   my ($self) = @_;
   my $files = $self->find_PL_files;

   while (my ($file, $to) = each %$files) {
     unless ($self->up_to_date( $file, $to )) {
       $self->run_perl_script($file, [], [@$to]);
       $self->add_to_cleanup(@$to);
     }
   }
}

Under what conditions does it fail to clean up?

Thanks,
Randy.

[Module::Build] Re: META.yml feature for autotesters?

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

Chris Dolan <ch...@cl...> wrote:
> The prereq_action_types feature seems to be undocumented, so I'll  
> leave it to someone more experienced to explain the right way to add  
> a build_recommends...

	Sounds interesting, I'll have to look into that a bit more. From a
quick glance it looks like prereq_action_types is only used a few times in
the source. The "blead" META.yml spec doesn't say anything about
build_recommends... Ken, is build_recommends currently the desired way for a
META.yml to tell testers what packages they should install to do the most
complete test pass possible?

	Cheers,
		Tyler

Re: [Module::Build] ./Build on Win98

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

Dr Bean wrote:
> On Wed, 22 Feb 2006, Randy W. Sims wrote:
> 
>>> I also just realized that my initial attempts depend on $0
>>> which wont work for our API clients; I'll get this cleaned up.
> 
>> This is hopefully fixed now in CVS, and a new snapshot is up also[1] if 
>> I can beg one more test.
> 
> I found a different Win98 machine with ActiveState
> 5.8.7.815. After running perl Build.PL:
> 
> D:\greg\Module-Build>dir Build
> 
>  Volume in drive D has no label
>  Volume Serial Number is 4658-17D7
>  Directory of D:\greg\Module-Build
> 
>    BUILD    PL          2,591  02-02-06   8:19 Build.PL
>    BUILD                1,472  02-24-06  22:00 Build
>    BUILD    BAT         1,943  02-24-06  22:00 Build.bat
>             3 file(s)          6,006 bytes
> 	             0 dir(s)       13,728.44 MB free
> 
> 
> D:\greg\Module-Build> Build realclean
> Deleting _build
> Deleting Build
> Deleting Build.bat
> Batch file missing

It's taking the wrong path here. M::B is deleting 'Build.bat' where it 
should be letting it delete itself. We know this method of self-deletion 
works because it was proved in a previous attempt. The only issue here 
is that the created 'Build.bat' is not correctly passing in the 
--build_bat argument. To prove this you should be able to:

   perl Build.PL
   Build --build_bat realclean

and get a successful run without error about missing batch file.

If you run:

   perl Build.PL

and then look at the top of the resulting 'Build.bat', you should see 
the following lines:

if "%OS%" == "Windows_NT" goto WinNT
perl -x -S "%0" "--build_bat" %1 %2 %3 %4 %5 %6 %7 %8 %9
goto endofperl
:WinNT
perl -x -S "%0" "--build_bat" %*

I'd like to know if the resulting 'Build.bat' differs on Win9x. I 
suspect not. Otherwise the invokation of perl from the batch file would 
cause errors or different behavior.

At one time those quotes around the --build_bat arg seemed necessary, 
but it may be the cause of the problem; Although, I don't see why they 
should matter one way or the other. I've removed those quotes, and 
instrumented the code to see if I can find out where the argument is going.

Care to give it another spin?

   <http://thepierianspring.org/perl/Module-Build.tar.gz>

   perl Build.PL
   Build realclean
   if exist Build.bat echo profanity

How many cases do I owe you now?

Randy.

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

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

On Fri, Feb 24, 2006 at 05:04:37PM -0600, Ken Williams wrote:
> 
> On Feb 24, 2006, at 11:17 AM, Yitzchak Scott-Thoennes wrote:
> 
> >On Sun, Feb 19, 2006 at 10:10:07PM -0800, Yitzchak Scott-Thoennes  
> >wrote:
> >>In case it helps move things further along, here's Craig's stuff as a
> >>patch to CVS, with Tie::CPHash added.  Passes all tests using cygwin
> >>and windows ActivePerl 5.8.7.  I don't see any reason not to apply  
> >>it.
> >>(I made the last change be for VMS only.)
> >
> >Ping?
> 
> 
> Hi Yitzchak,
> 
> I just got my laptop recovered this morning from a hard-drive crash  
> over the weekend.  That's why I've been completely out of touch - bad  
> timing!
> 
> To help my memory get back up to speed: is Tie::CPHash required just  
> for testing, or also in runtime?  Stuff in t/bundled/ is only used  
> during building and testing, not installed during the 'install' action.

Just testing, and apparently really just for VMS, but I think it's
be better to have all tests go through the same code, so have all
platforms use it.

Re: [Module::Build] UNINST=1?

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

On Feb 21, 2006, at 11:35 AM, Tyler MacDonald wrote:

> Randy W. Sims <ml...@th...> wrote:
>>> It turned out I had to write "uninst=1" (lower case). I think we  
>>> should
>>> either support the uppercase method, or somehow change the  
>>> warning message
>>> that is displayed. In fact, doing both might be preferable. :)  
>>> The first
>>> option is trivial ... I think the second one falls into this domain:
>>
>> The first option would set bad precedent. We'd then have people  
>> wanting
>> direct translations of all MakeMakeresqe options. verbose, prefix,  
>> etc.
>
> 	Yeah, that's another thing I was going to mention. This subclassing
> thing is great and all, but I really miss being able to just write  
> a "sub
> MY::postamble" to paste makefile snippets for me... can we get that  
> put into
> Module::Build as well?
>
> 	...
>
> 	Kidding!

Dude, you almost sent me into some kind of manic rage! =)


> Seriously though, there's been quite the debate about
> PREFIX and it sounds like people are working to get that into
> Module::Build...

No, it's actually been done for quite a while now in the 0.27_xx  
branch - yet another reason we really need to get that branch out the  
door.


> I can understand Module::Build behaving differently where
> it provides a technological advantage, but when there's a feature  
> that's
> supported by both MM and MB and the difference is just a matter of
> commandline syntax or terminology, shouldn't we be making MB's  
> syntax as
> close as possible to MM's (or at least support MM's) to smooth the
> transition?

Yeah - my motto here is "compatible where possible".  Definitely  
where it's possible to support EU::MM compatibility, we should do so.

  -Ken

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

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

On Feb 24, 2006, at 11:17 AM, Yitzchak Scott-Thoennes wrote:

> On Sun, Feb 19, 2006 at 10:10:07PM -0800, Yitzchak Scott-Thoennes  
> wrote:
>> In case it helps move things further along, here's Craig's stuff as a
>> patch to CVS, with Tie::CPHash added.  Passes all tests using cygwin
>> and windows ActivePerl 5.8.7.  I don't see any reason not to apply  
>> it.
>> (I made the last change be for VMS only.)
>
> Ping?


Hi Yitzchak,

I just got my laptop recovered this morning from a hard-drive crash  
over the weekend.  That's why I've been completely out of touch - bad  
timing!

To help my memory get back up to speed: is Tie::CPHash required just  
for testing, or also in runtime?  Stuff in t/bundled/ is only used  
during building and testing, not installed during the 'install' action.

  -Ken

Re: [Module::Build] ./Build on Win98

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

On Fri, 24 Feb 2006 13:32:19 -0600, Joshua ben Jore wrote:

Hi Joshua

> there's no borders so you have to guess what text belongs in what

IE displays borders on all tables on that page.

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

[Module::Build] Re: META.yml feature for autotesters?

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

[NOTE: I trimmed the CC list to just module-build-general, since my  
answer reflects only that system]

On Feb 24, 2006, at 2:51 PM, Tyler MacDonald wrote:

> 	I've been thinking about automated testing again. I know this is a
> bad habit and I should stop it and just get on with my work, but  
> here's
> where I'm at:
>
> 	Sometimes it's beneficial for an automated tester to install
> additional packages (in software I'm releasing, Test::CPANpm and  
> sqlite are
> perfect examples). It would be good to have a standard way to tell  
> a smoke
> tester what these packages are.
>
> 	How does everybody feel about making this a defined "feature" in
> the META.yml spec? Something like:
>
> optional_features:
>   - automated_testing:
>       description: Automated testing of all of this package's features
>       requires:
>         DBD::SQLite2: 0
>
> 	If an optional_feature field for packages useful for automated
> testing was standardized, functionality could be added to  
> CPAN::YACSmoke and
> PITA to take advantage of it, and then there would be an easy way  
> for an
> author to define prerequisites for doing an exhaustive smoke test  
> of their
> distribution.
>
> 	What do y'all think?

M::B briefly included a 'build_recommends' property that did about  
what you propose.  The idea was that people would put  
Test::Pod::Coverage and the like in that field.  It was removed in  
0.27_04 in favor of the more customizable prereq_action_types()  
feature.  That feature avoids the overwhelming combinatorics of  
{,build_,test_,install_}{requires,recommends,conflicts} etc. most of  
which were rarely used.

Here's the explanation from the Changelog:

    0.27_04  Fri Dec 23 10:43:34 CST 2005
     - Removed experimental feature that extended the prerequisite  
system
       to apply ('requires', 'recommends', and 'conflicts') prereqs  
to all
       actions. Most of the internal extensiblity has been retained so
       that prereq types can easily be added, more selectively.

The prereq_action_types feature seems to be undocumented, so I'll  
leave it to someone more experienced to explain the right way to add  
a build_recommends...

Chris
-- 
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] META.yml feature for autotesters?

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

	I've been thinking about automated testing again. I know this is a
bad habit and I should stop it and just get on with my work, but here's
where I'm at:

	Sometimes it's beneficial for an automated tester to install
additional packages (in software I'm releasing, Test::CPANpm and sqlite are
perfect examples). It would be good to have a standard way to tell a smoke
tester what these packages are.

	How does everybody feel about making this a defined "feature" in
the META.yml spec? Something like:

optional_features:
  - automated_testing:
      description: Automated testing of all of this package's features
      requires:
        DBD::SQLite2: 0

	If an optional_feature field for packages useful for automated
testing was standardized, functionality could be added to CPAN::YACSmoke and
PITA to take advantage of it, and then there would be an easy way for an
author to define prerequisites for doing an exhaustive smoke test of their
distribution.

	What do y'all think?

	Thanks,
		Tyler

Re: [Module::Build] ./Build on Win98

[Joshua b. J. <tw...@gm...>]

On 2/24/06, Nick Ing-Simmons <ni...@in...> wrote:

> >http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/filei=
o/fs/createfile.asp
>
> Well that flag is a help, but not suffient, as a browse of URL above conf=
ims:
>   A. It don't work on Win9x like things.

I had to read the source of the HTML to see which item the "doesn't
work on Windows 9x/ME" belonged to. It was to the previous flag, not
the one I mentioned.

Not that it matters much since it isn't going to do the job here *anyway*..=
.

I just mention that it's easy to read that page and think it says the
flag doesn't work on 9x/ME. The table cells aren't aligned nicely and
there's no borders so you have to guess what text belongs in what row
(or read the source).

Josh

[Module::Build] PL_Files and add_to_cleanup

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

I was noticing that if I create some files using a .PL script that I 
listed in the PL_FILES hash, that these files are not automatically 
deleted when running './Build distclean' (or realclean or clean). 
Shouldn't they be automatically added to the add_to_cleanup files?  I 
cannot think of a use case where these files shouldn't be deleted (since 
they are always overwritten by Build).

I can produce a patch if that would be acceptable.

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] ./Build on Win98

[Nick Ing-S. <ni...@in...>]

Joshua ben Jore <tw...@gm...> writes:
>On 2/22/06, Nick Ing-Simmons <ni...@in...> wrote:
>> Randy W. Sims <Ra...@Th...> writes:
>
>> Build.bat cannot delete itself on Windows.
>> You can't delete executing things. This is why Windows needs to
>> reboot after installing upgrades.
>> A running thing can ask for a delete on next reboot, but cannot delete
>> an open file.
>
>You can have it delete itself if you can manage to call the CreateFile
>Win32 API function with the FILE_FLAG_DELETE_ON_CLOSE flag. At least
>that's what demerphq told p5p about something similar when trying to
>get M::B to be able to install Cwd.

And there was a whole thread ...

>
>http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/fileio/=
fs/createfile.asp

Well that flag is a help, but not suffient, as a browse of URL above confim=
s:
  A. It don't work on Win9x like things.
  B. It don't work if there is an _existing_ open other than ours unless th=
at=20
     open had other ANOTHER flag set.=20
     Does cmd.exe set FILE_SHARE_DELETE access when it opens Build.bat ?


>
>Josh

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

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

On Sun, Feb 19, 2006 at 10:10:07PM -0800, Yitzchak Scott-Thoennes wrote:
> In case it helps move things further along, here's Craig's stuff as a
> patch to CVS, with Tie::CPHash added.  Passes all tests using cygwin
> and windows ActivePerl 5.8.7.  I don't see any reason not to apply it.
> (I made the last change be for VMS only.)

Ping?

Re: [Module::Build] ./Build on Win98

[Dr B. <gr...@mo...>]

On Wed, 22 Feb 2006, Randy W. Sims wrote:

> >I also just realized that my initial attempts depend on $0
> >which wont work for our API clients; I'll get this cleaned up.

> This is hopefully fixed now in CVS, and a new snapshot is up also[1] if 
> I can beg one more test.

I found a different Win98 machine with ActiveState
5.8.7.815. After running perl Build.PL:

D:\greg\Module-Build>dir Build

 Volume in drive D has no label
 Volume Serial Number is 4658-17D7
 Directory of D:\greg\Module-Build

   BUILD    PL          2,591  02-02-06   8:19 Build.PL
   BUILD                1,472  02-24-06  22:00 Build
   BUILD    BAT         1,943  02-24-06  22:00 Build.bat
            3 file(s)          6,006 bytes
	             0 dir(s)       13,728.44 MB free


D:\greg\Module-Build> Build realclean
Deleting _build
Deleting Build
Deleting Build.bat
Batch file missing

D:\greg\Module-Build>dir Build

 Volume in drive D has no label
 Volume Serial Number is 4658-17D7
 Directory of D:\greg\Module-Build

BUILD    PL          2,591  02-02-06   8:19 Build.PL
         1 file(s)          2,591 bytes
         0 dir(s)       13,728.67 MB free


But now it is hanging on subtest 12 of t\basic.t

-- 
Dr Bean                          Success is going from failure
                                 to failure without a loss of
                                 enthusiasm-- Winston Churchill