Re: switching t_cmp() argument order
Geoffrey Young [EMAIL PROTECTED] wrote: hi all before it gets too late I would like to change t_cmp() to t_cmp($received, $expected, $comment); so that test writers can feel at home in either environment. for the most part the change would be transparent to users as long as their tests pass. the only exception is qr// tests, which would error out now and force a recode. there's not much we can do about that except to make the switch sooner rather than later I guess. [EMAIL PROTECTED]:~ % perl -e '$a = qr/this/; print ref $a;' echo Regexp Perhaps do a test and swap the arguments if the first is a Regexp, as well as issue a deprecation warning. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
[RFC] Apache::Build
I've been moving several of my Perl modules from MakeMaker to
Module::Build. I'm not seeing support for Module::Build in the
Apache::Test suite, so I thought I'd take a stab at subclassing
Module::Build to provide support for it.
I couldn't access the searchable archives for this list (get sent
back to http://www.apache.org/), but I did look through this month's
archive and didn't see anything obvious along this line.
Several questions before I jump even more head-long into this.
(1) Is Apache::Build a sensible, everyday name? Should it perhaps
reside instead under Module::Build or Apache::Test? I have no
problem with this module being its own distribution on CPAN. I also
have no problem contributing it to an existing project.
(2) How DWIMmy should it be? I like the following for my Build.PL
(as a goal):
use Apache::Build;
my $build = Apache::Build-new (
module_name = 'Apache::Foo',
license = 'perl',
requires = {
'perl' = '5.6.1',
'Some::Module' = '1.23',
'Other::Module' = '= 1.2, != 1.5, 2.0',
},
);
$build-create_build_script;
It should just work :) This would also make any t/*.PL files into
t/* files.
(3) Support for multiple versions of Apache/mod_perl.
I'm also thinking about adding (at least) two functions to
Module::Build's API in the subclass (doc's based on those from
Module::Build):
check_apache_status($version)
This method returns a hash reference indicating whether a version
dependency on Apache is satisfied. The $version argument can take
any of the forms described in the requires entry in the
Module::Build manpage. This allows very fine-grained version
checking.
The returned hash reference has the following structure:
{
ok = $whether_the_dependency_is_satisfied,
have = $version_already_installed,
need = $version_requested, # Same as incoming $version argument
message = $informative_error_message,
}
If no version of Apache is currently installed, the have value will
be the string none . Otherwise the have value will simply
be the version of Apache installed.
This method may be called either as an object method (
$build-check_apache_status($version) ) or as a class method (
Apache::Build-check_apache_status($version) ).
check_apache_version($version)
Like check_apache_status(), but simply returns true or false
depending on whether Apache statisfies the dependency $version.
If the check succeeds, the return value is the actual version of
Apache installed on the system. This allows you to do the
following:
my $apache2 = $m-check_apache_version('2');
if ($apache2) {
print Building for Apache 2.x.\n;
}
else {
die You must have Apache 2.x installed for this module.\n;
}
If the check fails, we return false and set $@ to an informative
error message.
If $version is any nontrue value (notably zero) and any version of
Apache is installed, we return true.
In general you might prefer to use check_apache_status if you need
detailed information, or this method if you just need a yes/no
answer.
I might add a few more as I get into it, but those come to mind right
now. I think it might be possible to check mod_perl's version with
the existing check_module_version method, but I'll do some more
looking/digging/thinking.
I'd also like to see if it's possible to add support for building
mod_perl 1.x and mod_perl 2.x modules from the same distribution --
basically put Stas's code into this somewhere.
Thanks.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Senior Software Applications Developer,
Texas AM CIS Operating Systems Group, Unix
Re: [RFC] Apache::Build
James G Smith [EMAIL PROTECTED] wrote: I've been moving several of my Perl modules from MakeMaker to Module::Build. I'm not seeing support for Module::Build in the Apache::Test suite, so I thought I'd take a stab at subclassing Module::Build to provide support for it. So I don't appear too ignorant, I did just find the Apache::Build module in the mod_perl 1.99_09 distribution :/ But the basic idea remains, I think -- something based on Module::Build that hides a lot of the boilerplate and possible complexity of setting up Apache::Test and building/testing Apache modules. /me goes back to reading and thinking -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage---
[ This message is resent on behalf of James G Smith [EMAIL PROTECTED].
-- justin ]
Stas Bekman [EMAIL PROTECTED] wrote:
We have a problem with using the Apache::Test name, more correctly we have a
problem with using the Apache/Test.pm filename. On platforms with
case-insentive filesystems (winFU, Mac OS X) if mod_perl 1.x is installed,
there is Apache/test.pm (notice the lower case 't'). So when you say 'use
Apache::Test' it loads Apache::test. Boom, nothing works.
There are several routes we can take to resolve this problem:
1. rename Apache::Test to something else. David Wheeler has proposed to use
Apache::Tester (or even swap the sides: Test::Apache).
As much work as it would require at this point (going through and
changing all the package names, renaming files, munging CVS), I think
Test::Apache would fit in better.
What convinced me of this was a look at my test code. At the top, ignoring
the code to test for availability, I basically have (under the new name):
use Test::Apache qw(plan have ok skip);
use Test::Apache::Request qw(GET);
plan tests = $some_number, have 'LWP';
# rest of tests here
__END__
In my non-Apache modules, I have:
use Test::More;
plan tests = $some_number;
# rest of tests here
__END__
There's a nice symmetry here.
Of course, I had to go and try combining the two :) They seem to
work. I am able to use Test::More to plan and report testing while I
use Apache::TestRequest to do the fetching. This undercuts a little
the argument for Test::Apache being the better name. We still need
the Apache::TestRequest version of GET because it knows where the
test server is.
use Test::More;
BEGIN {
eval {
require Apache::TestRequest;
Apache::TestRequest - import(qw(GET));
};
}
my @required = qw(
Apache::Test
Apache::TestRequest
DBD::CSV
HTML::Mason
LWP
);
my @unavailable;
if(@unavailable = grep { ! eval require $_ } @required) {
plan skip_all = The following modules are unavailable:
. join( , @unavailable);
exit 0;
}
plan tests = 1;
my $res = GET /mason/test1.html;
ok $res-content eq '[This is a Mason Page]
';
exit 0;
__END__
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
---End Message---
