Hi All,
Here's a new subclass for Module::Build, Apache::TestMB, which allows
modules that use Module::Build to run tests using Apache::Test. My
assumption is that it would be distributed with Apache::Test; therefore
its use is something like this:
use Module::Build;
my $build_pkg = eval {
On Jun 21, 2004, at 8:12 PM, David Wheeler wrote:
Hi All,
Here's a new subclass for Module::Build, Apache::TestMB, which allows
modules that use Module::Build to run tests using Apache::Test. My
assumption is that it would be distributed with Apache::Test;
therefore its use is something like
On Jun 21, 2004, at 8:29 PM, Ken Williams wrote:
I see - so the author would design their tests so they could be run
either with or without a live server? I'm guessing many authors would
want to require a live server, and thus rely on Apache::TestMB.
Most module authors design their tests to
On Jun 21, 2004, at 6:12 PM, David Wheeler wrote:
Here's a new subclass for Module::Build, Apache::TestMB, which allows
modules that use Module::Build to run tests using Apache::Test.
Let me make a few comments on my XXX comments in the source code, and
aske a couple of questions:
* In
On Mon, 21 Jun 2004, David Wheeler wrote:
[ ... ]
* This isn't commented in the code I sent you, but I'll
note it: I didn't implement cmodules or cmodules_clean
actions. They appear simple, but they seem to depend on
`make` rather than Module::Build. Stas, are these just
that simple? Should
On Jun 22, 2004, at 6:23 AM, Ken Williams wrote:
./Build help should work already. ./Build help $newaction should work
automatically if you add documentation for each action - it searches
for docs using the regex /^=item\s+\Q$action\E\b/ .
Ah, I had =item Caction. I'll remove the C.
Thanks,
On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote:
Right now the Makefile is generated by methods within
Apache/TestConfigC.pm, which generally consists of calling
the apxs utility to compile the module (as well as
implementing a 'clean' target). In principle I think this
could be done via
On Jun 22, 2004, at 10:33 AM, Stas Bekman wrote:
Absolutely. It's really just:
MyTest-new-run(@ARGV);
where MyTest is a subclass of Apache::TestRunPerl
I tried that, but it didn't work. I'm not sure why. The first problem
was this code:
$0 = File::Spec-rel2abs($0);
if (-e $0) {
Oops, sorry for the dupe.
David
David Wheeler wrote:
On Jun 22, 2004, at 10:33 AM, Stas Bekman wrote:
Absolutely. It's really just:
MyTest-new-run(@ARGV);
where MyTest is a subclass of Apache::TestRunPerl
I tried that, but it didn't work. I'm not sure why. The first problem
was this code:
$0 = File::Spec-rel2abs($0);
On Tue, 22 Jun 2004, David Wheeler wrote:
On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote:
Right now the Makefile is generated by methods within
Apache/TestConfigC.pm, which generally consists of calling
the apxs utility to compile the module (as well as
implementing a 'clean' target).
On Jun 22, 2004, at 12:19 PM, Randy Kobes wrote:
Sure, it should be relatively straightforward ... But I'd
like to get, especially, Stas' opinion on this - adding this
in will necessarily introduce a few branches in the
Apache/TestConfigC.pm code related to, first of all, whether
to write a
David Wheeler wrote:
How are you going to avoid that? I mean your users need to be able to
run certain features of Apache-Test, which are beyond 'make test'. May
be you want to always create t/TEST, but run 'make test' without
invoking t/TEST?
I meant that I wanted to avoid dealing with it.
On Jun 22, 2004, at 2:44 PM, Stas Bekman wrote:
It may be a fairly complex logic to add, though you could write
wrappers that simply push things into @ARGV, emulating the command
line.
Though I'd rather have one way to do things. It's already a
non-trivial thing with all the multiple options.
David Wheeler wrote:
On Jun 22, 2004, at 2:44 PM, Stas Bekman wrote:
It may be a fairly complex logic to add, though you could write
wrappers that simply push things into @ARGV, emulating the command line.
Though I'd rather have one way to do things. It's already a
non-trivial thing with all
On Jun 22, 2004, at 3:15 PM, Stas Bekman wrote:
Yes, but it won't work for modules not using MB, so it's better to
have something common. We can always change things later if we find it
beneficial. Nothing is cast in stone as long as it doesn't add a huge
overhead for the user's learning curve.
16 matches
Mail list logo
